Nextmail

Create segment

createSegment

Save a segment: a name and the conditions a contact has to meet. It holds no contacts of its own, so who matches is worked out each time it is used. previewSegment counts the matches first without saving anything. Nothing is sent.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "conditions": "<conditions>"
    },
    "name": "createSegment"
  }
}

Input Schema

Name	Required	Description
`name`	Yes
`match`	No	all (the default) when a contact has to meet every condition, any when one is enough.
`conditions`	Yes	Each condition names a `field` and an `operator`: `email` (`is`, `is_not`, `contains`, `not_contains`, `ends_with`), `name` (`is`, `is_not`, `contains`, `not_contains`, `is_set`, `is_not_set`), `source` (`is`, `is_not`), `created` (`within_days`, `not_within_days`), `audience` (`in`, `not_in`), `opened` (`within_days`, `not_within_days`), `clicked` (`within_days`, `not_within_days`), `engaged` (`within_days`, `not_within_days`), `event` (`within_days`, `not_within_days`), `attribute` (`is`, `is_not`, `contains`, `not_contains`, `is_set`, `is_not_set`). Text is compared without regard to case, and `value` holds what it is compared with. `source` compares how the contact was added. `created`, `opened`, `clicked` and `engaged` take `days`: when the contact was added, the last time they opened or clicked a tracked email from this workspace, and the later of those two. A contact who never opened has not opened within any number of days. `audience` takes `audienceId` and counts only subscribed members. `event` takes `event`, a name recorded with `POST /events`, and `days`. `attribute` takes `key`, the name of a custom field on the contact.
`description`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 25, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare non-read-only, non-destructive, closed-world, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the segment is dynamic (stores no contacts, membership is recomputed on use) and 'Nothing is sent' rules out the send side effect that sibling tools like sendToAudience carry. It does not mention validation failures or duplicate-name behavior.

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

Conciseness5/5

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

Four short sentences, front-loaded with the definition, then the dynamic-membership behavior, then the alternative, then the no-side-effect note. Each sentence carries distinct information; nothing is padded.

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

Completeness4/5

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

For a create mutation with no output schema, the description covers what is stored, how matching works, and what does not happen (no send). What an agent might still want — returned identifier, duplicate-name handling, the 20-condition cap — is left to the schema or unstated, but nothing essential is missing.

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

Parameters3/5

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

Schema coverage is 50%, but the two heaviest parameters — `match` and `conditions` — carry dense inline schema documentation (per-field operator mappings, `days`/`audienceId`/`event`/`key` semantics). The description only names `name` and `conditions`, leaving `match` and `description` entirely to the schema, which is the correct baseline of 3 at this coverage level.

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

Purpose5/5

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

States a specific verb (save) and resource (segment) and defines what a segment is: a name plus conditions a contact must meet. It also names the sibling it is not — 'previewSegment counts the matches first without saving anything' — so the agent can separate the two without opening either schema.

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

Usage Guidelines4/5

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

Explicitly routes the agent toward previewSegment for dry-run counting, which covers the main alternative an agent would consider. It does not address updateSegment/deleteSegment or what to do when a name already exists, so the routing is clear but not exhaustive.

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

All Nextmail tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.