Skip to main content
Glama
Sign In
Mautic MCP Connector

Mautic MCP Connector

by si-essence
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

mautic_add_contact_to_segment

Idempotent

Adds a contact to a Mautic segment by segment and contact ID, with an optional dry-run preview before executing the write.

Instructions

Add a contact to a segment. POST /api/segments/{segmentId}/contact/{contactId}/add. Omit confirm for a dry-run preview.

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": {
      "segment_id": "<segment_id>",
      "contact_id": "<contact_id>"
    },
    "name": "mautic_add_contact_to_segment"
  }
}

Input Schema

NameRequiredDescriptionDefault
confirmNoSet to the boolean true to execute the write. Omit this field for a dry-run preview. false and the string true are rejected.
contact_idYes
segment_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the non-read-only, idempotent, non-destructive profile, so the bar is lower, but the description adds something annotations cannot express: the explicit confirm-to-execute vs omit-for-preview safety contract. It omits what a successful call returns and how an already-present contact is handled, though idempotentHint implies that case.

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

Conciseness4/5

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

Three short sentences, front-loaded with the action and followed by the route and the safety caveat. The raw POST path is of limited value to an agent but does confirm parameter ordering; nothing is padded or redundant.

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

Completeness3/5

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

For a two-required-parameter write with no output schema, the definition covers the action, the identifiers, and the dry-run gate, which is the core need. It leaves out error conditions (invalid segment/contact, already-member behavior) and any notion of what a preview versus an executed call yields, so it is adequate rather than complete.

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

Parameters3/5

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

Schema coverage is only 33%, so the description must compensate — and it does so only partially. The route template clarifies that segmentId and contactId are path identifiers, but it adds no format or type detail for them, while the confirm semantics are already spelled out at length in the schema itself.

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

Purpose4/5

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

States a specific verb and resource ("Add a contact to a segment") and pins the exact HTTP route, which makes the operation unmistakable and clearly distinct from mautic_remove_contact_from_segment or mautic_add_contact_to_campaign. It stops short of naming a sibling explicitly, so it sits just below the top mark.

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

Usage Guidelines4/5

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

Provides a real usage rule: omit confirm to get a dry-run preview, otherwise the write does not happen. That tells the agent how to safely probe before mutating. It gives no guidance on when to prefer this tool over adjacent operations, so no exclusions are covered.

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

Deploy Server

Other Tools