Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@send16-mcp Send a test email from onboarding@send16.com to my account with subject 'It works'."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The email API your AI agent can actually use. A Model Context Protocol server for Send16 that gives Claude, Cursor, and any MCP client 79 tools to send transactional & marketing email, manage contacts, audiences, segments, automations, templates, the inbox, suppressions, and webhooks — from natural language.
It ships a zero-DNS sandbox sender, so an agent can send its first real, delivered email in seconds with no domain setup.
npx send16-mcpYou need a Send16 API key (sk_live_…) from your dashboard. Then pick your client:
claude_desktop_config.json (macOS: ~/Library/Application Support/Claude/, Windows: %APPDATA%\Claude\):
{
"mcpServers": {
"send16": {
"command": "npx",
"args": ["-y", "send16-mcp"],
"env": { "SEND16_API_KEY": "sk_live_..." }
}
}
}.cursor/mcp.json:
{
"mcpServers": {
"send16": {
"command": "npx",
"args": ["-y", "send16-mcp"],
"env": { "SEND16_API_KEY": "sk_live_..." }
}
}
}Windsurf, VS Code, and any stdio-capable MCP client work the same way — run the send16-mcp binary with SEND16_API_KEY in the environment.
For clients that only speak remote MCP (Claude web connectors, ChatGPT custom GPTs), point them at the hosted endpoint and authenticate with your key:
https://mcp.send16.comOne connection, your own sk_live_… key — no install, no config file.
Related MCP server: sendook-mcp
Most email APIs make you verify a domain before you can send anything, which blocks an unattended agent on step one. Send16's sandbox sender doesn't:
Ask the agent to call whoami — it returns your workspace and your sandbox_recipient (your account owner's email).
Send from: "onboarding@send16.com" to that address. It delivers with zero DNS setup.
Verify a domain later to send to anyone.
"Send a test email from onboarding@send16.com to my account email with the subject 'It works'."
79 tools across the platform, including:
Email — send_email (single/batch/scheduled/attachments), transactional templates, delivery status.
Marketing — campaigns, broadcasts, automations, segments, subscription topics.
Contacts — create/search/list/import, audiences, tags, custom fields.
Deliverability — domains, DNS health (SPF/DKIM/DMARC), IP warming & sending capacity.
Inbox — read and manage transactional replies.
Webhooks — create/list/rotate outgoing webhook endpoints (HMAC-SHA256 signed).
Every tool also accepts an optional apiKey parameter that overrides SEND16_API_KEY, so you can switch workspaces in one session.
Variable | Required | Description |
| Yes | Your Send16 key ( |
| No | API base URL (default: |
| No | If set, serves Streamable HTTP (multi-tenant) instead of stdio |
Presence of SEND16_MCP_PORT flips the server into multi-tenant HTTP mode — each request carries its own Authorization: Bearer sk_live_…, threaded through the whole request, so one process serves many users:
docker build -t send16-mcp . && docker run -p 4242:4242 send16-mcpnpm install
SEND16_API_KEY=sk_live_... npm run dev # run from source
npm run build # bundle to dist/Site & docs: https://send16.com · https://send16.com/docs
Status: https://status.send16.com
MIT © Spruik Co
Activate an automation. New events matching its triggers will start enrolling contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| automationId | Yes | Automation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the behavioral effect ('starts enrolling contacts'), which adds value beyond the name, but does not cover idempotency, permissions, reversibility, or side effects. A score of 3 reflects minimal but non-trivial behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences, zero wasted words. The first sentence states the action, the second explains the consequence. This is ideal for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple activation tool with well-documented schema parameters and no nested objects or output schema, the description sufficiently covers the primary behavior. It could mention return value (void vs status), but given low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (apiKey and automationId). The tool description adds no additional detail about parameter usage, format, or constraints, so it provides no extra value beyond schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Activate an automation') and explains the functional result ('New events matching its triggers will start enrolling contacts'). This distinguishes it from sibling tools like pause_automation (which stops enrollment) and enroll_in_automation (which triggers one-time enrollment).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'pause_automation' or conditions under which activation is appropriate. Usage context is only implied by the tool's purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add contacts (by ID) to an audience.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| audienceId | Yes | Audience ID | |
| contactIds | Yes | Contact IDs to add |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic action. It does not disclose whether adding is idempotent, whether duplicate contact IDs are ignored, whether the audience must exist, or any side effects. Lacks behavioral context beyond the minimal description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. However, it is so brief that it may be under-specified, slightly reducing conciseness value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and only 3 parameters, the description is insufficient. It does not explain what happens on success, error cases, or how the tool fits into the larger workflow (e.g., requires existing contacts).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema; it only restates 'by ID' which is already clear from the contactIds parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add contacts') and the resource ('to an audience'), specifying that contacts are identified by ID. It distinguishes from sibling tools like 'remove_contact_from_audience' implicitly, but does not explicitly differentiate from 'import_contacts' which might also add contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'import_contacts' or 'create_contact'. There is no mention of prerequisites (e.g., contacts must exist) or when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a private internal note on a conversation. Notes are visible only to workspace members.
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Note body (markdown supported) | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| convoId | Yes | Conversation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses visibility (visible to workspace members) but does not mention other behavioral traits such as whether the note can be edited later, if notifications are sent, or error scenarios. The disclosure is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, with no wasted words. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool with 3 parameters and no output schema, the description adequately explains the tool's purpose and a key behavioral nuance (visibility). It does not cover return values or error handling, but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add significant meaning beyond what the parameter descriptions already provide. It confirms that body is the note content and convoId is the conversation, but the schema already states this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (add), the object (private internal note on a conversation), and a key property (visible only to workspace members). This distinguishes it from sibling tools like send_reply or update_convo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for internal notes but does not explicitly state when to use this tool versus alternatives like send_reply or create_contact. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register a new sending domain. Returns the DNS records the user must add to their DNS provider, after which they should call check_domain_health to verify.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| domain | Yes | FQDN to register (e.g. 'mail.example.com') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the registration action and the return of DNS records. However, it lacks details on side effects (e.g., what happens if domain already exists), required permissions, or idempotency, which are important for a mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and provides a clear follow-up step. No unnecessary words or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input (domain), output (DNS records), and the follow-up step (check_domain_health). It lacks mention of error handling or prerequisites, but for a 2-param tool without output schema, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; both parameters (apiKey, domain) are described in the schema. The description does not add new meaning beyond what the schema provides, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Register' and the resource 'a new sending domain', distinguishing it from its sibling 'check_domain_health' which is mentioned explicitly. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: register a new domain. It also tells the user what to do after ('call check_domain_health to verify'). However, it does not explicitly mention when not to use it or alternatives beyond check_domain_health.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add an email to the suppression list. Future sends to this address will be blocked.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| notes | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| reason | No | manual |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the effect of blocking future sends, but lacks details on reversibility, permanence, or required permissions. Since no annotations are provided, the description carries the full burden and is only partially sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with no wasted words. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description omits critical context: what happens if the email is already suppressed, how to specify a reason, and whether this is reversible. The tool's behavior is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (25%). The description does not explain the 'notes' or 'reason' parameters, leaving their purpose implicit. Only the email's role is inferred from context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add'), resource ('suppression list'), and outcome ('Future sends...blocked'). It distinguishes from siblings like 'remove_suppression' and 'list_suppressions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., remove_suppression, list_suppressions). No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the DNS health of a specific domain, including DKIM, SPF, DMARC, and MX record verification status. Triggers a fresh DNS lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| domainId | Yes | Domain ID to check health for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states 'Triggers a fresh DNS lookup', informing the agent of potential latency or cost. It lists the records checked but does not mention error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. Information is front-loaded: the main purpose first, then the fresh lookup trigger.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description lacks information about what the response looks like and how errors are reported. It covers what it checks but not the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and resource 'DNS health of a specific domain', listing exact record types (DKIM, SPF, DMARC, MX). It clearly distinguishes from sibling tools like add_domain and list_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for health checks but does not explicitly state when to use this tool versus alternatives like get_deliverability_status or add_domain. No exclusion criteria or 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.
Create an Action that maps an event name to a transactional template. Each matching event sends one email to the contact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| enabled | No | ||
| sendOnce | No | Only send once per contact regardless of how many times the event fires | |
| eventName | Yes | Event name to match (e.g. 'order.placed') | |
| delaySeconds | No | Delay before sending | |
| templateSlug | Yes | Transactional template slug to send |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden. It mentions that matching events send one email, but lacks details on side effects (e.g., idempotency, duplicates, permissions, rate limits) beyond this basic behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded, and contains no unnecessary words. Every sentence is meaningful and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters (3 required) and no output schema. The description does not mention the return value, success indicators, or error handling, leaving the agent without information on how to interpret the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 86%, so most parameters are already documented. The description adds the context that eventName and templateSlug are used for mapping, but does not elaborate on other parameters like apiKey, enabled, etc. beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an Action that maps an event to a transactional template and sends an email. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like create_webhook or create_campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, conditions, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new audience.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides zero behavioral context (e.g., side effects, permissions, limits). The agent gains no insight beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (6 words), which is concise, but it sacrifices necessary detail; it is not overly verbose but is under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, and vague parameter descriptions, the tool description fails to provide a complete understanding of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the tool description adds no information about parameters; the 'name' and 'description' fields remain unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new audience.' clearly states the action (create) and resource (audience), but does not differentiate from sibling 'create' tools like 'create_campaign' or 'create_contact'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no prerequisites, context, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new email campaign in Send16. The campaign is created in draft status and can be edited before sending.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Campaign name (internal label) | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| replyTo | No | Reply-to email address | |
| subject | Yes | Email subject line | |
| fromName | Yes | Sender display name | |
| fromEmail | Yes | Sender email (must be from a verified domain) | |
| previewText | No | Preview text shown in inbox alongside subject |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the campaign is created in draft status, a key behavioral trait, but does not mention what the tool returns, error handling, or authentication requirements. With no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the core purpose. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential purpose and draft status but lacks information about return values, error scenarios, and prerequisites. Given 7 parameters and no output schema, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond the schema, which has 100% coverage. Per guidelines, baseline 3 applies when schema coverage is high and description adds no extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new email campaign in Send16, specifying the verb 'create' and the resource 'email campaign'. It also mentions the draft status, which distinguishes it from sending or updating campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when creating a campaign and notes it can be edited before sending, but it does not explicitly state when not to use this tool or provide alternatives. Sibling tools like update_campaign and send_campaign are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add a new contact to your Send16 audience. Contacts are automatically subscribed to receive emails.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tag names to assign to this contact | |
| Yes | Contact email address | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| lastName | No | Contact last name | |
| firstName | No | Contact first name | |
| customFields | No | Custom field key-value pairs |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions auto-subscription but omits critical details: handling of duplicate emails, confirmation emails, rate limits, or success/failure behavior. The agent lacks sufficient behavioral context to use this tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant information, front-loaded with the core action. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters (including nested objects) and no output schema or annotations, the description is too sparse. It fails to explain return value, error cases, or duplicate contact behavior, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information beyond what the schema already provides, but does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Add a new contact) and the resource (Send16 audience), and distinguishes from siblings like update_contact and delete_contact by specifying 'Add a new contact' and noting auto-subscription.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests use for adding new contacts, but provides no explicit guidance on when to use this tool versus alternatives like import_contacts or add_contacts_to_audience, nor any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new subscription topic. Contacts opt into topics individually via the preference center.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Display name shown to contacts | |
| slug | No | URL-safe slug (auto-derived from name if omitted) | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| isDefault | No | Auto-subscribe new contacts to this topic | |
| description | No | Description shown in the preference center |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description adds behavioral context: topics are opt-in via preference center. Beyond what schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with all necessary high-level information, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a creation tool, description could mention return value (e.g., created topic object or ID). Otherwise adequate given parameter richness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 5 parameters. Description adds no extra parameter-level meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it creates a new subscription topic and adds context about opt-in via preference center. Distinguishes from siblings like delete_topic, update_topic, and list_topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when creating a new topic, but no explicit when-not-to-use or alternatives. Sibling names suggest typical CRUD pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register an outgoing webhook endpoint. Send16 POSTs event JSON to this URL with an HMAC-SHA256 signature. Outgoing webhooks are a plan feature.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS endpoint to receive events | |
| name | Yes | A label for this endpoint | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| events | Yes | Event types to subscribe to | |
| enabled | No | Whether the endpoint is active (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions HMAC-SHA256 signature but omits side effects, permissions, or idempotency. Minimal behavioral disclosure for a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff. Slight clarity issue: 'Send16' likely a typo for 'Sends' or 'Send 16'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema. Description does not explain return value (e.g., webhook ID, secret). Lacks critical info for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 5 parameters with descriptions. The description adds no new parameter info, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Register an outgoing webhook endpoint' clearly states the verb and resource. Distinguishes from sibling tools like list_webhooks, delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives. The phrase 'Outgoing webhooks are a plan feature' hints at prerequisites but lacks actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an Action.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| actionId | Yes | Action ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only repeats the tool's name without disclosing behavioral traits like destructiveness, permissions, or side effects beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence with no waste. However, it lacks any structural elements like front-loading key info, but it is appropriately short for a simple delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description is too minimal. It does not explain what an action is, prerequisites, side effects, or error conditions, which are needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond the schema, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete an Action.' clearly states the action and resource. It distinguishes from siblings like create_action, update_action, and get_action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives. No exclusions, prerequisites, or context for using this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an audience (list). Contacts are not deleted — only the list and its memberships are removed.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| audienceId | Yes | Audience ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that only the list and memberships are removed, not the contacts themselves. However, it does not cover potential side effects, authorization requirements, or rate limits, leaving some gaps for a deletion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Front-loads the action and essential caveat. Every sentence is necessary and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and only two simple parameters, the description is fairly complete. It explains the core operation and clarifies the effect on contacts. Missing return value info is acceptable for a simple delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (apiKey, audienceId). The description offers no additional meaning beyond what the schema provides, placing it at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an audience (list)' using a specific verb and resource. It further clarifies that contacts are not deleted, distinguishing this tool from similar operations like removing contacts from audiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives such as remove_contact_from_audience or add_contacts_to_audience. The description implies usage by stating what happens, but lacks when-not-to-use or workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a draft campaign. Sent campaigns cannot be deleted (only archived).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool deletes draft campaigns and that sent campaigns cannot be deleted, but it does not mention permissions, irreversibility, or side effects, leaving a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and includes a critical constraint. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the basic functionality and a key constraint. However, without annotations, it lacks details on irreversibility and permissions, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (apiKey and campaignId) with 100% coverage. The description adds no additional parameter information, so it meets the baseline standard.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'draft campaign', immediately conveying the tool's purpose. It distinguishes itself from sibling tools by specifying that only draft campaigns are deleted, and notes that sent campaigns are not handled here.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: this tool is for deleting draft campaigns only. It explicitly states a when-not condition ('Sent campaigns cannot be deleted'), but does not specify an alternative tool for archiving sent campaigns, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a contact and all associated events. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| contactId | Yes | Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly states the operation is irreversible and that associated events are also deleted, providing essential behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no extraneous information. Every word adds value, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with two parameters, the description is sufficiently complete. It covers the irreversible nature and scope (associated events), which is adequate given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both parameters (apiKey and contactId). The description adds no new parameter semantics; the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('delete') and resource ('contact'), and explicitly mentions the irreversible nature and associated events, clearly distinguishing it from siblings like create_contact or update_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deletion but lacks explicit when-to-use guidance or alternatives compared to siblings. It is adequate for a straightforward operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a subscription topic. All subscribers will be detached.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| topicId | Yes | Topic ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds one behavioral detail: 'All subscribers will be detached.' This is useful but incomplete—no mention of permissions, reversibility, or error conditions. Since no annotations exist, the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence with no unnecessary words. Front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with 2 parameters and no output schema, the description covers the core action and a key side effect. Could mention error handling or prerequisites, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both parameters described in schema). The description adds no additional parameter meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('subscription topic'), distinguishing it from sibling tools like create_topic or update_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't mention that update_topic might be used instead for modifying settings, or that deletion is irreversible.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an outgoing webhook endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| webhookId | Yes | Webhook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as irreversibility, required permissions, or side effects (e.g., does deleting a webhook affect active integrations?). For a destructive operation, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the action. However, it is almost too minimal; it could include a bit more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but for a simple delete operation the description is adequate. However, it lacks information about the response or error conditions. Given the low complexity, this is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. It adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('outgoing webhook endpoint'). It is specific and distinct from sibling tools like create_webhook and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., regenerate_webhook_secret). No prerequisites or context for when deletion is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use AI to generate a complete email HTML template based on a description. Returns ready-to-use HTML that can be sent or used in campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Type of email template to generate | |
| style | Yes | Visual style/aesthetic for the template | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| brandColor | No | Primary brand color as hex code (e.g. "#4F46E5") | |
| companyName | No | Company or brand name to include in the template | |
| description | Yes | Detailed description of the email content and purpose (e.g. 'Welcome email for a SaaS product with feature highlights and CTA to start trial') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states returns ready-to-use HTML but does not disclose side effects (e.g., does it save the template? Is it read-only?), API key usage beyond schema, or AI behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with purpose and outcome. Front-loaded and efficient, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 6 parameters (3 required, enums) and no output schema. Description mentions 'ready-to-use HTML' but fails to clarify whether the generated template is persisted in the account, which is relevant given sibling tools for templates (get_template, list_templates). Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter has adequate description. The tool description adds no further meaning beyond what the schema provides (e.g., not explaining enum options or apiKey behavior). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a complete email HTML template from a description, using AI. It uses specific verb 'generate' and resource 'email HTML template', distinguishing it from siblings like send_email, render_email_content, and generate_email_from_url which focus on sending or rendering existing content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like generate_email_from_url or render_email_content. The description does not mention when not to use it or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Duplicate a campaign as a new draft. Useful for A/B variants or re-using a successful template.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention side effects, required permissions, whether the duplicate is a full copy, or what happens to the original campaign. The phrase 'as a new draft' is helpful but insufficient detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous words. The primary action is front-loaded, and the use cases follow logically. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain expected return value (e.g., the new campaign ID), any constraints (e.g., campaign status requirements), and what is duplicated. It lacks these details, leaving the agent with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('duplicate a campaign') and the outcome ('as a new draft'). It distinguishes from siblings like 'create_campaign' and 'update_campaign' by specifying duplication. The use cases ('A/B variants or re-using a successful template') reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contexts for using the tool (A/B testing, template reuse). It does not explicitly list when not to use it or mention alternatives, but the intended usage is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually enroll a contact in an active automation. The automation must be in 'active' status. Use send_event for event-driven enrollment.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| contactId | Yes | Contact UUID (use search_contacts to look up by email first) | |
| automationId | Yes | Automation ID to enroll into |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions manual enrollment and the active status requirement, but does not describe side effects (e.g., if contact already enrolled), authentication needs, or success/failure indications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action and precondition, no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers the main action and precondition. It provides an alternative tool hint. However, it could mention potential failure modes like enrollment in a paused automation or duplicate enrollment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds extra guidance for contactId ('use search_contacts to look up by email first') and for apiKey, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'enroll' and the resource 'contact in automation', with the condition 'active' status. It distinguishes from sibling 'send_event' for event-driven enrollment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that automation must be active and directs to use 'send_event' for event-driven enrollment, providing clear context for when to use this tool vs an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scrape a URL (e.g. a launch blog post or product page) and generate an email draft from its content. Returns subject, preview text, and HTML body.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public URL to scrape and turn into an email | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| instructions | No | Additional guidance — e.g. 'announcement style, focus on the new feature' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool scrapes a URL and returns subject, preview text, and HTML body, but lacks details on side effects, authentication requirements (beyond the API key parameter), or any rate limits. The behavior is minimally described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences that front-load the purpose and immediately detail the output. Every word contributes value with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description compensates by listing the return values (subject, preview text, HTML body). With full schema coverage and a straightforward purpose, the description is sufficient, though it could mention the expected output format or size.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter adequately described. The tool description adds a usage example for the 'url' parameter ('e.g. a launch blog post or product page'), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (scrape a URL and generate an email draft) and the resource (content from a URL). It distinguishes itself from siblings like 'design_email_template' and 'send_email' by focusing on URL-based generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with examples ('e.g. a launch blog post or product page'), indicating appropriate use cases. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single Action with its trigger config and template binding.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| actionId | Yes | Action ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the response includes 'trigger config and template binding', which goes beyond the input schema. It implicitly indicates a read operation but does not mention auth requirements, rate limits, or error states. For a simple retrieval tool, this is sufficient but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without any fluff. Every word is necessary, and it is front-loaded with the key action and result.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 2 parameters (100% schema coverage) and no output schema, the description provides all essential context: what the tool returns (Action with trigger config and template binding). No additional information is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning to the parameters beyond what the schema already provides (actionId is an ID, apiKey is for overriding env var). No extra usage details or constraints are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a single Action with its trigger config and template binding' clearly specifies the verb (Get), resource (Action), and adds scope ('single') and included details (trigger config, template binding). It distinguishes itself from sibling tools like list_actions (which returns multiple) and create_action/update_action (which modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need a specific action by ID, but it does not explicitly state when to use this tool versus alternatives like list_actions or get_automation. No exclusions or prerequisites are mentioned, though the actionId parameter requirement is clear from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single automation by ID, including its trigger, steps, and current status.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| automationId | Yes | Automation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool returns, but fails to disclose whether the operation is read-only, any authentication requirements, rate limits, or side effects. The behavioral aspect is minimally addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the main purpose and includes the key aspects of the return value (trigger, steps, status). No unnecessary words; every part contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does mention the return content (trigger, steps, status), which is helpful. However, it lacks details on error handling, authorization, or rate limits. For a simple retrieval tool, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes both parameters (apiKey, automationId). The description adds no additional meaning beyond what the schema provides, placing it at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', resource 'single automation by ID', and the scope 'including its trigger, steps, and current status'. It distinguishes the tool from sibling tools like list_automations or get_automation_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a specific automation ID and need full details, but does not explicitly state when to use this tool versus alternatives like list_automations or get_automation_stats. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get aggregate analytics for an automation: total enrollments, completed, exited, open/click rates per step.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| automationId | Yes | Automation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states what the tool returns, without mentioning whether it is read-only, authentication requirements, rate limits, or any side effects. For a data retrieval tool, it fails to confirm it has no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Front-loaded with the core action and resource, followed by a list of included metrics. Every part is informative with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists key metrics but does not specify the output structure (e.g., whether it returns an object with fields like totalEnrollments and an array of step stats). Since there is no output schema, more detail on the return format would make it complete. Still, it provides enough for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters described in the schema. The description does not add any additional meaning beyond what the schema provides (apiKey and automationId are straightforward). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'aggregate analytics for an automation', listing concrete metrics (total enrollments, completed, exited, open/click rates). This clearly distinguishes it from siblings like 'get_automation' (which returns automation details) and 'list_automation_enrollments' (which lists individual enrollments).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining aggregate analytics, but provides no explicit guidance on when to use it instead of alternatives (e.g., 'list_automation_enrollments' for individual enrollments) or any conditions under which it should not be used. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the workspace's brand settings: colors, logo, fonts, and the DESIGN.md spec injected into AI generation prompts.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds useful context about what the brand settings include (DESIGN.md injection). It implies read-only behavior but does not disclose authentication requirements, rate limits, or side effects beyond the apiKey parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no wasted words. Highly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter), no output schema, and no annotations, the description is nearly complete. It explains what the tool returns, but could benefit from mentioning potential errors or default behavior when apiKey is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the sole parameter (apiKey). The tool description does not add meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves workspace brand settings, listing specific items (colors, logo, fonts, and DESIGN.md spec). It distinguishes itself from the sibling `update_brand` as a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or not use this tool vs alternatives. However, as a simple getter, context is implicit; no exclusions 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 detailed performance statistics for a specific campaign including open rate, click rate, bounce rate, and delivery metrics.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID to get stats for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only implies a read operation without mentioning side effects, data availability timing, or limitations like rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it lacks structure that could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though no output schema exists, the description lists key metrics returned. However, it omits details like completeness of metrics, historical data, and integration with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning for parameters. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed performance statistics for a specific campaign, listing specific metrics like open rate and click rate, which distinguishes it from sibling tools like get_automation_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool, prerequisites (e.g., campaign must be sent), or alternatives. It lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a contact's 0-100 health score based on recent engagement (opens, clicks, replies).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| contactId | Yes | Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool reads health scores based on recent engagement but does not disclose whether it is read-only, any authentication requirements, rate limits, or side effects. The description is minimal and does not add behavioral context beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two parameters and no output schema, the description is mostly complete. However, it lacks information on the return format (e.g., JSON object with score) and does not compensate for the missing output schema. It is adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning both parameters (apiKey, contactId) are described in the schema. The description adds no additional meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a 0-100 health score based on recent engagement (opens, clicks, replies). It specifies the verb 'get' and the resource 'contact health score', and the output range and inputs are clear. It is distinct from sibling tools like get_contact_timeline which provide detailed history, though it could be more explicit about differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., get_contact_timeline for detailed engagement). Usage is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a contact's full activity timeline: emails received, events fired, opens, clicks, automation enrollments, topic changes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| cursor | No | Pagination cursor | |
| contactId | Yes | Contact ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention rate limits, authorization needs, whether it's read-only, or what happens on invalid contactId. It only describes the data returned, lacking transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose. Every word adds value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description partially compensates by listing the types of activities returned. However, it omits pagination behavior (implied by cursor parameter) and error handling. Still, it is fairly complete for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all four parameters described. The description adds overarching context (what the response includes) but does not add meaning to individual parameters beyond the schema. Baseline 3 is appropriate given high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'contact's activity timeline'. It enumerates the types of activities included (emails, events, opens, etc.), distinguishing it from sibling tools like get_contact_health_score or list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a contact's full activity timeline, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, leaving the agent to infer usage context from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single conversation with its full thread of posts (incoming + outgoing).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Conversation ID | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it retrieves data (non-destructive) but does not mention any limitations, authentication requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one required parameter and no output schema, the description adequately explains what is returned (full thread of posts). Could mention metadata, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds no additional meaning beyond what is in the schema, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'a single conversation with its full thread of posts (incoming + outgoing)', distinguishing it from list_convos and other conversation-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_convos or when not to use it. The description lacks 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 your workspace's deliverability summary — sending reputation, domain authentication status, and recent bounce/complaint health. (Deliverability Hub plan feature.)
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses that the tool returns a summary with specific data points and hints at a plan requirement, but does not elaborate on whether it's read-only (obvious from context), authentication requirements, or potential rate limits. The disclosure is adequate for a simple get operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the tool's purpose and a usage note (plan feature) in parentheses. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and simple parameters, the description provides a reasonable overview of what the response contains (reputation, domain auth, bounce/complaint health). It also mentions a plan restriction. It could be improved by specifying the return format or error conditions, but for a get tool, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, as the single parameter 'apiKey' is documented in the schema. The tool description does not add any additional meaning beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the workspace's deliverability summary including sending reputation, domain authentication, and bounce/complaint health. The verb 'get' and resource 'deliverability summary' are specific, and the sibling tools list shows no other deliverability-specific tool, distinguishing it effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving deliverability status, and notes it's a 'Deliverability Hub plan feature' which provides a precondition. However, it does not explicitly state when to use versus alternatives or mention any exclusions, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single message with its full event timeline (created → sent → delivered → opened → clicked → ...).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Message ID | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states that it returns the event timeline, but does not mention read-only nature, authentication requirements, rate limits, or any other side effects. This is minimal disclosure for a tool with two parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose. It is front-loaded with the verb 'Fetch'. However, it could include more contextual information without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with no output schema, the description adequately states what is returned ('full event timeline'). It is sufficient for an experienced developer but lacks details on the structure of the timeline or any error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes both parameters adequately. The description adds no extra meaning beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource 'a single message', and what is included ('full event timeline'). This distinguishes it from siblings like 'list_messages' or 'get_message_events'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single message with timeline but does not explicitly state when to use this tool versus alternatives like 'list_messages' or 'get_message_events'. No exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get just the delivery event timeline for a message — no body or recipient details.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Message ID | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It states the tool gets delivery events, but does not disclose what events are included (e.g., sent, delivered, bounced) or any side effects/permissions, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single compact sentence that front-loads the core purpose and adds a clarifying exclusion, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description only hints at 'delivery event timeline' without specifying structure (e.g., list of events, timestamps). For a low-complexity tool, this is acceptable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (id and apiKey), so description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'delivery event timeline for a message' and explicitly excludes 'body or recipient details', distinguishing it from get_message and other sibling tools like get_contact_timeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when only delivery events are needed) by contrasting with get_message, but does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single starter template by ID, including its EmailContent JSON.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| templateId | Yes | Template ID (slug) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read operation but lacks details on idempotency, error cases, or response structure beyond mentioning EmailContent JSON. Minimal disclosure of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 2 parameters and no output schema, the description adequately conveys purpose and a key response detail (EmailContent JSON). It is sufficient for the tool's low complexity but could mention that it returns the full template object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the response but does not elaborate on parameter usage (e.g., templateId format, apiKey override). It adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a single starter template by ID and mentions the inclusion of EmailContent JSON. This differentiates it from list_templates (which lists) and design_email_template (which modifies). However, it doesn't clarify what distinguishes a 'starter template' from other templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, such as using list_templates first to obtain IDs, or that it is a read-only operation. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current workspace (the one the API key belongs to).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It accurately indicates a read operation, but lacks details on error conditions, rate limits, or authentication beyond the apiKey parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence with no redundancy, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one optional parameter and no output schema, the description is adequate. It could hint at the expected response structure, but the lack of that is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema's parameter description, which already explains the apiKey field. Baseline score of 3 is applicable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the specific resource 'the current workspace (the one the API key belongs to)', distinguishing it from sibling tools like list_workspaces or get_workspace_usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the API key owner's workspace but provides no explicit guidance on when to use this tool versus alternatives like list_workspaces or get_workspace_usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current month's send count, contact count, and plan limits.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only lists returned metrics but does not disclose safety, permissions, or rate limits. For a read operation, it assumes the agent knows it's non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Directly conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and no output schema, the description sufficiently describes what the tool returns. It is complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning to the single parameter (apiKey). The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'workspace usage', listing specific metrics (send count, contact count, plan limits). It distinguishes from siblings like 'get_workspace' which likely returns workspace metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many list/get tools, there is no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bulk import contacts from CSV data. Each row should have at minimum an email column. Tags can be applied to all imported contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tag names to apply to all imported contacts | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| csvData | Yes | CSV string with headers. Required column: "email". Optional: "firstName", "lastName", "tags" (comma-separated within quotes) | |
| updateExisting | No | Whether to update contacts that already exist |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions CSV import and tag application but does not clarify error handling, idempotency, rate limits, or authentication details beyond the apiKey parameter. The updateExisting behavior is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Every sentence provides essential information: the action and format, then the minimum requirements and optional tags. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the core functionality but misses details like return value, batch limits, or error behavior. It is adequate for a simple import tool but not thoroughly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying that each CSV row must have an email column and that tags apply to all imported contacts, which goes beyond the schema's parameter descriptions. However, it does not explain the CSV format in detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Bulk import'), the resource ('contacts'), and the data format ('CSV data'). It also specifies the minimum requirement (email column) and the ability to apply tags, making the tool's purpose distinct from sibling tools like create_contact (single contact) or add_contacts_to_audience (add to audience).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bulk imports but does not explicitly contrast with other contact-related tools (e.g., create_contact for single contacts, add_contacts_to_audience for adding to audiences). It lacks when-to-use or when-not-to-use guidance, relying on the user to infer from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Actions. Actions fire a transactional template when a custom event arrives — Plunk-style 'event_name → template' pairings, simpler than full automations.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'List Actions' which implies a read operation with no side effects. However, it does not disclose any behavioral traits like authentication requirements, rate limits, or pagination behavior. The description is adequate for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long: a clear verb+resource opener followed by a concise explanation of what actions are. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and only one optional parameter, the description is fairly complete. It explains the concept of actions and their relation to templates and automations. However, it could mention the default output format or that it lists all actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (apiKey) with schema description coverage at 100%. The description does not add any information beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'List Actions' (specific verb + resource) and then explains what actions are ('event_name → template' pairings) and how they differ from full automations. This clearly distinguishes it from sibling tools like create_action or list_automations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to list all action definitions, but it does not explicitly state when to use it or when not to (e.g., for a single action use get_action). The comparison to automations gives some context but no direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List audiences (lists). An audience is a static, manually-managed group of contacts.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like pagination, sorting, or result limits, which are typical for list operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no wasted words, and directly conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks details on pagination, ordering, or output format, which would be expected for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (apiKey) is fully described in the schema, and the description adds no extra semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists audiences and defines what an audience is, distinguishing it from sibling tools like list_contacts or list_segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to use list_contacts or list_segments instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active and historical enrollments for an automation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| cursor | No | ||
| automationId | Yes | Automation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as pagination (cursor parameter not explained), authentication (apiKey only hinted), rate limits, or whether it returns full enrollment objects. Insufficient disclosure for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with key information, no unnecessary words. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters and no output schema or annotations, description is incomplete. Missing explanation of pagination, filter options, return format, and required state parameter behavior. Not sufficient for an agent to use correctly without additional hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 40% schema description coverage, description does not compensate. Does not explain state enum values, cursor usage, or limit meaning beyond what schema provides. The mention of 'active and historical' only vaguely hints at the state filter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'List' and resource 'enrollments for an automation', clarifying scope with 'active and historical'. Clearly distinguishes from siblings like 'enroll_in_automation' and 'list_automations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_automations' or 'get_automation_stats'. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all automations in the workspace, including draft/active/paused status and trigger types.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It confirms read-only, non-destructive behavior but does not mention pagination, rate limits, or any side effects. Minimal transparency for an unannotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single 15-word sentence that is front-loaded and efficient. Every part of the description adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description covers the basic purpose and what is included (status, trigger types). However, it lacks guidance on usage relative to sibling tools and could benefit from mentioning the return format or pagination behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional parameter 'apiKey' is fully documented in the input schema (100% coverage). The description adds no additional meaning or context beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'automations', and scope 'in the workspace', and adds specific details about including status and trigger types. This distinguishes it from sibling list tools like list_audiences or list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_automation for a single automation, list_automation_enrollments for enrolled contacts). The description implies it's for listing all automations but doesn't provide explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List email campaigns with optional status filtering and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| status | No | Filter campaigns by status | |
| pageSize | No | Results per page (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It states listing with filtering and pagination, which is clear but lacks details on authentication, rate limits, or result shape. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 optional parameters and no output schema, the description is minimal. It does not explain return format, error handling, or pagination behavior beyond what the schema provides. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is already documented. The description reinforces the purpose of status and pagination but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List email campaigns with optional status filtering and pagination' uses a specific verb-resource pair, clearly distinguishing it from sibling tools like list_actions or list_audiences.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as list_campaign_stats or get_campaign_stats. The description does not mention exclusions or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all contacts with optional filtering by subscription status and tag. Supports pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| tagId | No | Filter by tag ID | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| pageSize | No | Results per page (max 100) | |
| subscribed | No | Filter by subscription status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination support and the ability to filter, implying a read-only operation. However, it does not explicitly state if it is destructive or what return format to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the main purpose and then adding key features. No extraneous information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering there is no output schema and no annotations, the description covers basic functionality but lacks details on authentication (apiKey), default ordering, and return format. Additionally, it does not clarify when to use this tool over siblings like search_contacts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by grouping parameters into functional categories ('filtering by subscription status and tag' maps to subscribed and tagId; 'pagination' maps to page and pageSize). This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all contacts with optional filtering, which directly indicates the verb and resource. It distinguishes from siblings like search_contacts by focusing on listing all with simple filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions optional filtering and pagination but does not provide explicit guidance on when to use this tool versus alternatives such as search_contacts. No exclusion criteria or context for when not to use it is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List inbox conversations. Filter by state, mailbox, label, screener status, or full-text search. Send16's unified inbox combines transactional reply threading with team-managed shared inboxes.
| Name | Required | Description | Default |
|---|---|---|---|
| label | No | Filter by label slug | |
| limit | No | Page size (default 50) | |
| state | No | Conversation state | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| offset | No | Page offset | |
| search | No | Full-text search across subject + body | |
| mailboxId | No | Filter to one mailbox | |
| screener_status | No | Screener gate status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the core behavior (listing with filters) but omits details like default sorting order, rate limits, or whether deleted conversations are excluded. The mention of 'unified inbox' adds context but is not directly behavioral.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the main purpose. The first sentence front-loads the action and filters. However, the second sentence about 'Send16's unified inbox' is slightly vague and could be replaced with more concrete behavior (e.g., pagination details).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not explain what is returned (e.g., conversation IDs, subjects, timestamps). Pagination parameters (limit, offset) are in schema but not described in terms of behavior (e.g., 'returns results in reverse chronological order'). For a listing tool, this is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The tool description merely echoes the filter options without adding extra semantic meaning. Baseline of 3 is appropriate since schema already documents parameters well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'List inbox conversations' with explicit filtering options (state, mailbox, label, screener status, full-text search). It distinguishes from sibling tools like get_convo (single conversation) and list_messages (messages within conversations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides basic use cases (listing with filters) but lacks guidance on when to use alternatives (e.g., search_contacts, list_inbox_counts) or when not to use this tool. No mention of pagination behavior or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sending domains configured in your Send16 workspace, including their verification status and DNS records.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description provides transparency by mentioning included fields (verification status, DNS records), which is sufficient for a read-only list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no wasted words. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema and one optional parameter, the description adequately conveys what the tool returns and its purpose, though pagination details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so description adds no extra semantics beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists sending domains with verification status and DNS records, distinguishing it from sibling tools like add_domain and check_domain_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for viewing all domains and their status, but lacks explicit when-not or alternative guidance. However, context is clear for a simple list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get unread/total counts per category and label for the inbox sidebar (newsletter, transactional, marketing, calendar, social, cold).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides the basic behavior—returning counts per category—but omits details on authentication requirements, rate limits, data freshness, or whether this is a read-only operation. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately communicates the tool's purpose. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers the core functionality. It could mention the response format or error handling, but overall it sufficiently informs an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single 'apiKey' parameter. The description does not add extra meaning beyond what the schema provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns unread/total counts per category and label for inbox sidebar, listing specific categories (newsletter, transactional, etc.). This distinguishes it from sibling tools like list_convos or list_messages, which deal with actual messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for displaying inbox sidebar counts but does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. No guidance on prerequisites 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 messages from the unified send log (transactional + campaign). Filter by recipient, sender, status, date range, or source.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (default 50) | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| offset | No | Page offset | |
| source | No | Restrict to one message source | |
| status | No | Delivery status filter | |
| to_email | No | Recipient email filter | |
| from_email | No | Sender email filter | |
| created_after | No | ISO-8601 timestamp lower bound | |
| created_before | No | ISO-8601 timestamp upper bound |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to disclose important behavioral traits such as pagination behavior, ordering, rate limits, data freshness, or permission requirements. The description only states basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action and resource, followed by filter summary. No wasted words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete given the complexity: 9 parameters, no output schema, no annotations. It fails to explain pagination (limit/offset), default ordering, potential large result sets, or the shape of the returned data. More context is needed for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a summary of filter categories (recipient, sender, status, date range, source) but does not provide new meaning beyond the schema. No note about default values or usage hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb ('List'), a specific resource ('messages from the unified send log'), and explicitly mentions filtering capabilities. It distinguishes from sibling tools like 'get_message' and other list tools by highlighting the unified log and filter options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving messages with filters but does not explicitly state when to use this tool versus alternatives like 'get_message' for single messages or other list tools. However, the naming and context are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List dynamic segments. Segments compute their members from a filter expression at send time.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Absent annotations, description adds context that segments compute members from filter expression at send time, but does not disclose pagination, return format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, description should indicate scope (all segments?), return format, or any filtering. It lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter (apiKey) with full description. Description adds no additional meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb+resource: 'List dynamic segments'. It distinguishes from sibling list tools (e.g., list_audiences, list_contacts) by specifying 'dynamic' and briefly explaining the concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like preview_segment or other list tools. 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.
List suppressed email addresses (bounces, complaints, unsubscribes, manual).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| offset | No | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must bear full burden. It does not disclose pagination behavior (though schema has limit/offset), auth requirements, rate limits, or return format. Minimal behavioral insight beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 8 words, no waste. Front-loaded verb and resource. Could be slightly more informative without losing conciseness, but currently efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is too minimal. It omits return type, pagination details, and usage context. For a listing tool, agent would need more to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%, and the description adds context for the 'reason' parameter by listing its possible values (bounces, complaints, unsubscribes, manual). However, it does not explain optional parameters like limit, offset, or apiKey, so value added is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List suppressed email addresses' with categories in parentheses, indicating verb and resource. While it implicitly distinguishes from siblings like add_suppression, it does not explicitly differentiate, but the verb 'list' is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like add_suppression or remove_suppression. Agent must infer context from sibling names, but no explicit when-to-use or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List starter-gallery email templates available to every workspace.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'list', which is implicitly read-only, but does not disclose authentication requirements (apiKey parameter), rate limits, or that it returns a list of templates. The minimal description lacks transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. However, it could be restructured to include more detail without losing conciseness. For a simple tool, it is efficient but perhaps too minimal for full clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what is returned (e.g., list of templates, structure). It does not mention return format, pagination, or whether the apiKey is required. With 1 optional parameter and no annotations, the description is incomplete for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only apiKey parameter), and the schema already describes its purpose. The description adds no additional meaning about the parameter. With high coverage, the baseline is 3, and the description does not improve or clarify parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'starter-gallery email templates', with the scope 'available to every workspace'. This distinguishes it from other list tools like list_campaigns or list_contacts, and from get_template which retrieves a single template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention of when to use list_templates instead of get_template, or how it differs from other list tools. The agent receives no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscription topics. Topics are granular categories contacts can subscribe to (e.g. 'product-updates', 'weekly-digest'). Campaigns and automations can be gated to subscribers of a specific topic.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'List subscription topics' with no mention of side effects, permissions, rate limits, or response format. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and valuable context. No unnecessary words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of return values (no output schema). No information on pagination, ordering, or expected response structure. Suitable for a simple list operation but has gaps given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (apiKey) documented. Description adds no additional meaning beyond the schema, but baseline is 3 since schema already covers the parameter. No extra context provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'List' and resource 'subscription topics', and adds context about what topics are and their use in campaigns/automations. However, it does not explicitly differentiate from sibling tools like list_audiences or list_segments, though the resource name is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as list_audiences or create_topic. The description mentions topics can gate campaigns/automations but does not state when listing is appropriate or what prerequisites exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured outgoing webhooks (your endpoints that Send16 POSTs delivery events to). Outgoing webhooks are a plan feature.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It describes a safe read operation ('List') and explains the purpose of webhooks. While it doesn't detail return behavior or plan-dependent errors, the tool is simple and side-effect-free, so transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences with no fluff. It immediately states the action, followed by a clarifying definition, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description covers the core functionality and plan restriction. However, it doesn't mention the return format (e.g., list of webhook objects) or any pagination, leaving some ambiguity about the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the parameter is well-described in the schema itself ('Send16 API key (overrides SEND16_API_KEY env var)'). The description adds no further parameter detail, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List configured outgoing webhooks' with a precise verb and noun, and clarifies what outgoing webhooks are—'your endpoints that Send16 POSTs delivery events to'. This clearly distinguishes the tool from siblings like create_webhook or delete_webhook.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this to view existing webhooks. However, no explicit when-to-use or when-not-to-use guidance is provided. The mention 'Outgoing webhooks are a plan feature' implies a usage precondition but doesn't fully exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workspaces the authenticated user has access to (owner or member).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavior. It discloses that results are limited to workspaces where the user is owner or member. However, it does not mention pagination, ordering, or whether results include all workspace details. This is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It uses clear language and front-loads the core action. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is adequate but not complete. It lacks details on return format, pagination, or field information, which could be important for an agent to fully understand the response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (apiKey) is fully described in the input schema ('Send16 API key (overrides SEND16_API_KEY env var)'). The description adds no further semantic value beyond what the schema already provides, yielding a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('workspaces'), and specifies scope ('authenticated user has access to (owner or member)'). This differentiates it from sibling tools like 'get_workspace' which retrieves a single workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need a list of accessible workspaces) but does not explicitly state when to use this tool over alternatives like 'get_workspace' for details. No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark a conversation as read for the current viewer.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| convoId | Yes | Conversation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must disclose side effects, but it fails to mention impacts on other viewers, idempotency, or notification triggers. The action of marking as read is under-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff, but overly brief and missing essential usage details. Efficient but not sufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description should explain return value, error conditions, or side effects. None are provided, making it incomplete for an agent to confidently invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. Description adds no extra meaning beyond schema, resulting in baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Mark') and resource ('a conversation as read'), clearly distinguishing it from sibling tools like 'update_convo' or 'get_convo'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites mentioned (e.g., viewer being participant), and no exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause an automation. Existing enrollments freeze in place; no new contacts enroll.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| automationId | Yes | Automation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes immediate effects (freeze, no new enrollments) but lacks details on reversibility, permissions, or other side effects. With no annotations, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, no redundant information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pause action, description covers the primary behavior. Could mention if pausing affects ongoing triggers, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters (apiKey, automationId) with descriptions. The tool description adds no additional parameter meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Pause an automation' with specific verb and resource, and further explains behavioral effect: 'Existing enrollments freeze in place; no new contacts enroll.' This distinguishes from siblings like 'activate_automation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (pause an automation) but no explicit when-not or alternatives. However, the effect is clear enough to differentiate from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pause a sending campaign. Already-sent messages are unaffected; remaining sends halt.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes that already-sent messages are unaffected and remaining sends halt, which is useful. However, it omits details like permissions required, whether pause is reversible, or what happens if already paused.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences cover the action and key behavioral trait. No fluff; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple pause action, the description covers the main effect but lacks return value details, error handling, or state considerations (e.g., already paused campaign). Completeness is adequate but not robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond what the schema provides for the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The name 'pause_campaign' clearly indicates the action, and the description states 'Pause a sending campaign' with a specific verb and resource. It distinguishes from sibling tools like 'resume_campaign' and 'delete_campaign' by clarifying that already-sent messages are unaffected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pausing an active campaign but does not explicitly state when to use versus alternatives like 'resume_campaign' or 'delete_campaign'. No prerequisites or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run an AI pre-send review on an email's HTML before sending. Surfaces tone issues, broken links, missing alt text, spam triggers, and accessibility problems.
| Name | Required | Description | Default |
|---|---|---|---|
| html | Yes | Full HTML body to review | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| subject | Yes | Email subject line | |
| audience | No | Short description of the audience (helps tone analysis) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states what the tool surfaces. It does not clarify whether the tool is read-only, modifies anything, or has rate limits or authentication requirements beyond the apiKey parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with purpose front-loaded, followed by a list of issues surfaced. No wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema; description does not specify format of results or how to interpret them. For a review tool, more detail on return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. Description adds minor context (audience helps tone analysis) but does not enhance understanding of parameters beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'run an AI pre-send review' and specifies the resource 'email HTML'. It lists specific outputs (tone issues, broken links, etc.), distinguishing it from sibling tools like send_email or preview_campaign_recipients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Before sending' provides context, but there is no explicit guidance on when to use this tool versus alternatives like send_email, send_broadcast, or preview_campaign_recipients. No exclusions or when-not conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview the recipient set for a campaign before sending. Returns count + sample list.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns a count and sample list, implying a read-only operation, but does not disclose any side effects, limitations (e.g., sample size), or error conditions. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys core functionality efficiently. It is appropriately sized given the tool's simplicity, with no unnecessary words. Slight deduction for missing details that could be added concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the return format. 'Count + sample list' is helpful but underspecified (e.g., sample size limit, pagination). Error behavior and prerequisites are absent, making it somewhat incomplete for a preview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema definitions. It does not explain parameter usage context or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Preview' and the resource 'recipient set for a campaign', which distinguishes it from sibling tools like 'preview_segment' that target segments instead of campaigns. It is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage 'before sending' but does not explicitly state when to use or avoid this tool, nor does it mention alternatives among siblings. The context is clear but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview the contacts that match a segment without sending.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| segmentId | Yes | Segment ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly indicates no sending occurs, implying read-only behavior. However, it omits details like rate limits, required permissions, or whether the preview is real-time or cached.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words. Front-loaded with the action. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with few parameters; the description covers the core function. However, the output format is not described (e.g., list of contacts, count). Completeness is high for the tool's complexity but could be slightly improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description does not add new meaning beyond the schema; it reiterates that segmentId identifies the segment. Baseline 3 is appropriate as the schema already documents both parameters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Preview the contacts that match a segment without sending' clearly states the verb (preview), resource (contacts matching a segment), and subtly distinguishes from sending operations. It is specific and avoids ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for dry-run preview but does not explicitly state when to use this tool versus alternatives like search_contacts or preview_campaign_recipients. No when-not or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rotate the HMAC signing secret for an outgoing webhook endpoint. Returns the new secret once.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| webhookId | Yes | Webhook ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool rotates the secret and returns it once, but lacks details on what happens to the old secret, immediate invalidation, rate limits, or impacts on active webhooks. For a security-sensitive operation, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first clearly states the action and resource, the second states the return behavior. No extraneous information, front-loaded, and efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with two params and no output schema, the description covers the basic purpose and return. However, it omits details about side effects (e.g., webhook downtime) and prerequisites. While not critically incomplete, it could be more comprehensive for a security-sensitive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters. The description adds value by specifying that the secret is 'HMAC signing' and for an 'outgoing webhook', which provides context beyond the schema's parameter names and descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Rotate the HMAC signing secret' and the resource 'outgoing webhook endpoint', with a specific verb and resource. It distinguishes from sibling tools like 'create_webhook' or 'delete_webhook' by specifying rotation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for an existing webhook but provides no explicit guidance on when to use this tool versus alternatives, prerequisites, or when not to use it. No exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a contact from an audience.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| contactId | Yes | Contact ID | |
| audienceId | Yes | Audience ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose side effects (e.g., whether the contact is deleted or just unlinked), required permissions, or return value. Minimal behavioral info for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and object. No unnecessary words. Concise and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool but description lacks detail on whether removal is permanent, if the contact must exist, or if audience membership is affected. No output schema, so return value is unknown. Incomplete for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described in the schema. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Remove a contact from an audience' clearly states the verb (Remove) and resource (contact from audience). It distinguishes from sibling tools like add_contacts_to_audience or delete_contact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like delete_contact (which might fully delete the contact) or remove_suppression. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove an email from the suppression list. Use only when you've confirmed the recipient wants to receive mail again.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | |||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It states basic removal behavior but omits details like error handling, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words; front-loaded with action and usage condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple suppression removal tool, description covers purpose and when-to-use but lacks details on return values, error states, or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (email has format/pattern, apiKey has description). Description adds no additional parameter context, failing to compensate for uncovered parts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove an email from the suppression list') and is distinct from sibling tools like add_suppression and list_suppressions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use only when you've confirmed the recipient wants to receive mail again', providing clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compile an EmailContent JSON object (the shape used by the Send16 builder + templates) into HTML using the platform's authoritative renderer. Returns the exact HTML the API would send. Useful for previews and post-processing.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| content | Yes | EmailContent JSON (from get_template or the builder) | |
| variables | No | Variable replacements (e.g. {firstName:'Alice'}) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses core behavior (compiling to HTML, returning exact HTML). No annotations provided, so description must carry behavioral burden. Lacks details on error handling, preconditions (API key requirement), or safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. First sentence front-loads the core action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input, output (HTML), and use case. No output schema, but description states return type. Missing mention of errors or API key necessity, but sufficiently clear for a render tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with descriptions. Description adds context about content shape and origin ('from get_template or the builder') but adds minimal value beyond schema. Baseline 3 due to high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool compiles EmailContent JSON into HTML using the authoritative renderer and returns exact HTML for previews/post-processing. It distinguishes from siblings like send_email and design_email_template.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states usefulness for previews and post-processing, implying when to use. However, does not mention when not to use or explicitly name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resume a paused campaign.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| campaignId | Yes | Campaign ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action. It does not disclose prerequisites (e.g., campaign must be paused), side effects, or what happens if the campaign is already active.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. While it could include more context, it is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and high schema coverage, the description is minimally complete. However, it lacks behavioral details and usage guidance, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are documented in the schema. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Resume' and the resource 'paused campaign', directly indicating the tool's function. The sibling 'pause_campaign' provides clear distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used when a campaign is paused, which is clear given the sibling 'pause_campaign'. However, no explicit alternatives or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule (or send immediately) an existing draft campaign to an audience/segment/topic.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| topicId | No | ||
| segmentId | No | ||
| audienceId | No | ||
| campaignId | Yes | Campaign ID | |
| scheduleAt | No | ISO-8601 future datetime; omit to send immediately |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It adds the key behavioral trait that the tool can either schedule for a future time or send immediately. However, it does not disclose side effects (e.g., if scheduling changes campaign state), permissions required, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 14 words conveys the core functionality without waste. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and behavioral complexity (scheduling vs immediate send). Without an output schema, the description should hint at return values or success indicators. It does not explain parameter interactions, error states, or what happens after scheduling. This leaves the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description groups audienceId, segmentId, and topicId as targets, providing context beyond parameter names. However, it does not clarify mutual exclusivity (if one must be selected) or add constraints. With 50% schema coverage, more parameter explanation is needed to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('schedule' or 'send immediately'), the resource ('existing draft campaign'), and the target ('audience/segment/topic'). This distinguishes it from sibling tools like send_broadcast or create_campaign, which operate on different resources or states.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context—you schedule draft campaigns—but does not explicitly state when to use this tool versus alternatives (e.g., send_broadcast for sent campaigns, pause_campaign for pausing active campaigns). No when-not or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decide a pending screener conversation (first-time sender). 'allow' lets future emails through, 'reject' blocks, 'cold' marks as cold outreach.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| convoId | Yes | Conversation ID | |
| decision | Yes | Screener decision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral traits. It describes the immediate effects of each decision (allow, reject, cold) but does not explain if decisions are reversible, whether they trigger side effects, or what happens to future messages. This is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and resource. It prioritizes key information and avoids redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core functionality and decision options. However, it lacks information about the return value or any confirmation message, and does not mention prerequisites (e.g., the conversation must be pending and from a first-time sender). For a simple tool, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the tool description adds value by elaborating on the 'decision' enum: it explains what 'allow', 'reject', and 'cold' mean in the context of future email handling. This goes beyond the schema's 'Screener decision' description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Decide') and the resource ('pending screener conversation'), and explains the three possible decision outcomes. It distinguishes itself from sibling tools like list_convos or add_convo_note by specifying it's for screener decisions on first-time senders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use: for pending screener conversations from first-time senders. It does not explicitly state when not to use or provide alternatives, but the sibling set includes no other screener decision tool, making the guidance adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search contacts by email address or name. Returns matching contacts with their tags and subscription status.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| query | Yes | Search query (matches against email, first name, last name) | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| pageSize | No | Results per page (max 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions return fields but does not disclose pagination behavior or any side effects. The description is basic but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant information. Efficiently conveys core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must indicate return format—it does. However, it omits pagination details (though schema hints at it). Overall adequate for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by specifying return fields (tags, subscription status) not present in schema, improving understanding beyond parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches contacts by email or name and returns specific fields (tags, subscription status). It distinguishes itself from siblings like list_contacts by specifying search criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It only describes what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot broadcast: create a campaign and immediately schedule it to send. Mirrors Resend's one-call broadcast API. Pass either an audienceId, segmentId, topicId, or fully-qualified filter. Provide html OR templateSlug.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | Full HTML body (one of html/templateSlug required) | |
| name | Yes | Internal campaign name | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| replyTo | No | ||
| subject | Yes | ||
| topicId | No | Send to all subscribers of this topic | |
| fromName | Yes | ||
| fromEmail | Yes | Must be a verified domain | |
| segmentId | No | Send to all contacts matching this segment | |
| audienceId | No | Send to all contacts in this audience | |
| scheduleAt | No | ISO-8601 future datetime; omit to send immediately | |
| previewText | No | ||
| templateSlug | No | Workspace template slug to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool creates and immediately sends a campaign, but does not disclose potential side effects (e.g., costs, irreversibility), required permissions, rate limits, or what happens when 'scheduleAt' is used. The description is adequate but lacks depth for a high-stakes action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence front-loads the purpose, the second provides key constraints. Perfectly sized for a tool with 13 parameters; all information is earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 13 parameters, the description covers the core action and targeting/content constraints. It lacks explanation of 'fully-qualified filter' and return value, but overall it provides sufficient context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema by specifying mutual exclusivity constraints ('either audienceId, segmentId, topicId, or fully-qualified filter' and 'html OR templateSlug'), which are not enforced in the schema. With 69% schema coverage, the description compensates by clarifying parameter relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'One-shot broadcast: create a campaign and immediately schedule it to send', clearly indicating a combined create-and-send action. It differentiates from siblings like 'create_campaign' or 'schedule_campaign' by noting it is a single-call API that mirrors Resend's broadcast API.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidelines: 'Pass either an audienceId, segmentId, topicId, or fully-qualified filter. Provide html OR templateSlug.' This tells the agent which parameter combinations are valid. However, it does not explicitly state when not to use this tool versus alternatives like 'send_email' or 'schedule_campaign', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a test email for an existing campaign to preview how it will look in recipients' inboxes.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| testEmail | Yes | Email address to send the test to | |
| campaignId | Yes | Campaign ID to send test for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. While it correctly identifies the operation as a test (non-destructive), it lacks details on prerequisites (e.g., campaign must exist and be valid), potential side effects (e.g., rate limits), and whether it affects campaign state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. While it could be slightly more structured (e.g., broken into usage and behavior), it is highly concise and front-loads the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple test tool, the description covers the core purpose and usage. However, it omits expected output (e.g., success message or delivery status) and edge cases (e.g., invalid campaign ID). With no output schema, additional return information would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description does not add new parameter information beyond stating it is for an 'existing campaign.' Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send a test email'), the target resource ('an existing campaign'), and the purpose ('to preview how it will look in recipients' inboxes'). It distinguishes itself from sibling tools like 'send_broadcast' (sends to actual recipients) and 'preview_campaign_recipients' (previews who will receive).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('to preview how it will look'), suggesting it should be used before final sending. However, it does not explicitly state when to use or avoid this tool, nor does it mention alternatives like 'send_broadcast' for actual sending.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a transactional email through Send16. Provide html, text, or both (text-only is fine for OTPs/receipts/alerts). from_email must belong to a domain that is verified in the workspace — call whoami for the account and list_domains to see which senders are allowed; a send from an unverified domain returns a clear error, not a silent failure. For a zero-setup first send, use from_email onboarding@send16.com — the sandbox sender delivers with no DNS, but only to your own account email.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient email address or array of addresses (max 50) | |
| html | No | HTML body content | |
| text | No | Plain text body content | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| subject | Yes | Email subject line | |
| reply_to | No | Reply-to email address | |
| template | No | Transactional template slug to use instead of inline content | |
| from_name | No | Sender display name (e.g. "Acme Co") | |
| variables | No | Template variables for merge tags | |
| from_email | No | Sender email address (must be from a verified domain) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that unverified domains return a clear error, not silent failure, and mentions the sandbox sender for zero-setup. With no annotations, this is transparent, but lacks details on rate limits or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences efficiently convey core information. Front-loaded with the purpose. Could be slightly more concise but no redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers sending behavior and parameter usage well, but lacks information on return values, error handling, and response structure. For 10 parameters, more completeness would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds context on using html/text and domain verification for from_email, enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends transactional emails via Send16 and specifies the use of 'html', 'text', or both. It distinguishes from broadcast campaigns and other email-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use (transactional emails) and mentions prerequisites like domain verification. References sibling tools 'whoami' and 'list_domains' for setup. Lacks explicit exclusion of marketing emails.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fire a custom event for a contact. Automations whose trigger is {type:'custom_event', eventName:'<name>'} will enroll the contact and start running. Payload is exposed to condition steps as event.<key>.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Event name (e.g. 'trial_started', 'order.placed') | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| payload | No | Arbitrary JSON metadata available to automation conditions | |
| contactId | No | Contact UUID (provide either this or contactEmail) | |
| occurredAt | No | ISO-8601 timestamp; defaults to now | |
| contactEmail | No | Contact email (provide either this or contactId) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that automations trigger, payload is exposed to conditions, and mentions event name pattern. It does not cover rate limits or idempotency, but core behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core action, no redundancy. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested payload, and no output schema, the description explains the automation enrollment effect and payload exposure. Missing details on response/return value but sufficient for the tool's primary purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described inline. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('fire a custom event for a contact'), the resource (contact), and the trigger effect (automations with matching event name enroll the contact). It distinguishes from siblings like 'enroll_in_automation' by explaining it's event-driven.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the consequence (automation enrollment) but does not explicitly state when to use this tool vs alternatives (e.g., 'enroll_in_automation'). Usage is implied but not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to an inbox conversation. The reply is sent from the original recipient address (the alias the convo arrived on) and threaded back to the contact.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | HTML body of the reply | |
| text | No | Plain text body of the reply | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| convoId | Yes | Conversation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the reply comes from the original recipient address and is threaded, which is key behavioral info. However, it does not mention side effects, error scenarios, or permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Purpose is front-loaded. Achieves high information density without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lacks information about return values. It covers the main action well but omits what the response contains. Also does not mention that both html and text are optional, which may lead to an empty reply.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions; it does not clarify which body (html/text) is necessary or how apiKey interacts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Reply' and the resource 'inbox conversation'. It adds specific details about the reply being sent from the original recipient address and threaded, distinguishing it from sibling tools like send_broadcast or send_email.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for replying to a conversation but does not explicitly state when to use this tool versus alternatives (e.g., starting a new conversation with send_email). 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 an Action (toggle enabled, change template, change event name).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| enabled | No | ||
| actionId | Yes | Action ID | |
| sendOnce | No | ||
| eventName | No | ||
| delaySeconds | No | ||
| templateSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It indicates mutation ('update') but does not disclose behavior like side effects, idempotency, permissions, or atomicity. The described operations are simple, but deeper behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with zero waste. It front-loads the verb and resource, and immediately lists key capabilities.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters and no output schema or annotations, the description is insufficient. It does not mention required actionId, response format, or update semantics (e.g., partial vs full replacement). The tool is relatively complex, but the description provides minimal coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (25%). The description adds meaning for three parameters (enabled, eventName, templateSlug) but ignores others (name, apiKey, sendOnce, delaySeconds). It partially compensates but remains incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an Action' with specific examples (toggle enabled, change template, change event name). It distinguishes from sibling tools like create_action, delete_action, or list_actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing actions by listing updatable fields, but does not explicitly specify when to use vs alternatives or provide exclusions. The sibling context makes the purpose clear, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update workspace brand settings. The designSpec field is a Markdown DESIGN.md document fed into AI generation system prompts — use it to encode voice, do/don't lists, and visual rules.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| logoUrl | No | ||
| designSpec | No | Markdown DESIGN.md spec for AI generation | |
| fontFamily | No | ||
| primaryColor | No | Hex color (e.g. '#4F46E5') | |
| secondaryColor | No | Hex color |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals a critical behavioral trait: the designSpec field is used as a system prompt for AI generation. This adds significant value beyond the schema. However, it does not disclose other potential side effects, permissions, or immediacy of updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states purpose, the second provides essential parameter context. Every sentence earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, no output schema, and no annotations, the description covers purpose and one key behavioral detail but lacks information on success response, prerequisites (e.g., existing brand), and effects on other workspace elements. It is minimally adequate for a simple update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, the description only adds meaning to designSpec (explaining its role as a system prompt). For logoUrl and fontFamily, which lack schema descriptions, no additional information is provided. Thus, it partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates workspace brand settings, using a specific verb and resource. It distinguishes from siblings like get_brand (read) and design_email_template (template-level design).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating brand settings but does not explicitly guide when to use this tool versus alternatives like design_email_template or when not to use it. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a draft campaign's content, subject, preview text, or sender info.
| Name | Required | Description | Default |
|---|---|---|---|
| html | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| replyTo | No | ||
| subject | No | ||
| fromName | No | ||
| fromEmail | No | ||
| campaignId | Yes | Campaign ID | |
| previewText | No | ||
| templateSlug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It describes a mutation ('Update') but does not disclose required permissions, reversibility, or effect on campaign status. The response format is not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the action and resource. It is concise but could benefit from further detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, low schema coverage, and no output schema, the description is incomplete. It does not cover required status, optionality, or interaction with campaign state. The sibling tools suggest a rich campaign lifecycle, but no context is provided for when this tool fits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 22% (only campaignId and apiKey have descriptions). The description groups parameters (e.g., 'sender info' for fromName/fromEmail/replyTo) adding some meaning, but it lacks detail on format or constraints. The input schema provides patterns and formats, but their semantics are not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'draft campaign', and lists updatable fields (content, subject, preview text, sender info). It distinguishes from sibling tools like create_campaign and delete_campaign. However, it does not clarify that only draft campaigns can be updated, which may be a constraint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like schedule_campaign or send_campaign_test. There are no explicit when-to-use, when-not-to-use, or prerequisite conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a contact's profile fields, custom fields, or subscription state.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| lastName | No | ||
| contactId | Yes | Contact ID | |
| firstName | No | ||
| subscribed | No | ||
| customFields | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only indicates 'Update' (mutation) but lacks details on overwrite vs merge behavior, required permissions, side effects, or error conditions. Essential behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that efficiently communicates the core action and what can be updated. No extraneous words; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, nested objects (customFields), no output schema, and low schema description coverage, the description is too minimal. It omits return values, error handling, and parameter format details, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is low (33%). The description adds context by grouping parameters into 'profile fields, custom fields, or subscription state', which helps interpret firstName, lastName, subscribed, customFields. However, it does not explain customFields format or apiKey override, partially compensating for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'contact', specifying the updatable aspects: profile fields, custom fields, or subscription state. This precisely distinguishes it from sibling tools like create_contact, delete_contact, and add_contacts_to_audience.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, no when-not-to-use advice. The description gives no context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update conversation state (open/closed/snoozed/spam/trash), star, or assignee.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | New state | |
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| convoId | Yes | Conversation ID | |
| starred | No | Star/unstar | |
| assigneeId | No | Workspace member ID, or null to unassign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only mentions mutation but lacks details on side effects, permissions, or immediate updates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description does not explain return value or behavior when multiple params are set. Incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so schema already defines each parameter. The description does not add new meaning beyond listing actions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates conversation state, star, or assignee, using specific verbs and resource. It distinguishes itself from siblings like mark_convo_read and get_convo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., add_convo_note, send_reply). Agent must infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a subscription topic (name, description, default).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) | |
| topicId | Yes | Topic ID | |
| isDefault | No | ||
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only lists updatable fields but lacks behavioral context such as permissions, error conditions, or side effects of the update operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is concise and front-loaded with purpose. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple update tool with no output schema, description covers the basics. Could mention that it performs a partial update and that unchanged fields remain, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 40% (only apiKey and topicId described). Description adds meaning for three parameters (name, description, default) beyond schema, but could provide more detail on constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates a subscription topic and lists the updatable fields (name, description, default). It distinguishes from similar tools like create_topic and delete_topic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage (when you want to modify a topic) but no explicit guidance on when to use vs alternatives, 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.
Verify the API key and return the authenticated workspace: name, plan, email quota (used/limit), and owner. Call this first to confirm the key works before sending. Pair with list_domains to see which from addresses are allowed.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Send16 API key (overrides SEND16_API_KEY env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description adequately states it verifies the key and returns workspace info. Implied read-only behavior. Could explicitly mention no side effects, but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Front-loaded with purpose and includes actionable guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple verification tool: explains what it does, when to use it, and what it returns. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers 100% of the parameter meaning (apiKey). Description does not add new information beyond the schema; baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it verifies the API key and returns workspace details (name, plan, email quota, owner). This is specific and distinguishes from sibling tools like get_workspace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to call this first to confirm the key works before sending, and suggests pairing with list_domains. Provides clear when-to-use and contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.5.7activate_automationadd_contacts_to_audienceadd_convo_noteadd_domainadd_suppressioncheck_domain_healthcreate_actioncreate_audiencecreate_campaigncreate_contactcreate_topiccreate_webhookdelete_actiondelete_audiencedelete_campaigndelete_contactdelete_topicdelete_webhookdesign_email_templateduplicate_campaignenroll_in_automationgenerate_email_from_urlget_actionget_automationget_automation_statsget_brandget_campaign_statsget_contact_health_scoreget_contact_timelineget_convoget_deliverability_statusget_messageget_message_eventsget_templateget_workspaceget_workspace_usageimport_contactslist_actionslist_audienceslist_automation_enrollmentslist_automationslist_campaignslist_contactslist_convoslist_domainslist_inbox_countslist_messageslist_segmentslist_suppressionslist_templateslist_topicslist_webhookslist_workspacesmark_convo_readpause_automationpause_campaignpre_send_reviewpreview_campaign_recipientspreview_segmentregenerate_webhook_secretremove_contact_from_audienceremove_suppressionrender_email_contentresume_campaignschedule_campaignscreener_decidesearch_contactssend_broadcastsend_campaign_testsend_emailsend_eventsend_replyupdate_actionupdate_brandupdate_campaignupdate_contactupdate_convoupdate_topicwhoamiScored across 79 tools
Many tools exist for overlapping concepts (e.g., send_email, send_broadcast, send_campaign_test, send_reply; create_campaign vs schedule_campaign vs send_broadcast). While descriptions help, the large number of tools increases the chance of selecting the wrong one for a task.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., activate_automation, add_contacts_to_audience, send_event). No mixing of conventions like camelCase, making it predictable for an agent.
With 79 tools, this server is well beyond the recommended range. While it aims to cover a full email marketing platform, the sheer number makes it unwieldy and suggests it could be split into multiple focused servers.
The tool surface covers most major workflows (sending, contacts, campaigns, automations, analytics). However, notable gaps exist: no tools to create or update segments or email templates (only list/get), and no tag management tools.
Hosted email for AI agents: create inboxes, send, receive, and reply over MCP with scoped API keys
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email for AI agents — send, receive as a webhook, manage domains, templates, routing.
Marketo MCP server for AI. 130 tools to operate Marketo from Claude, Cursor, or ChatGPT.
