Mautic MCP Connector

mautic_get_stats

Read-only

Retrieve rows from a Mautic stats table with pagination, ordering, and filtering so you can query raw statistics for analysis or reporting.

Instructions

Read rows from a stats table. GET /api/stats/{table} with start, limit, order, and where.

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": {
      "table": "<table>"
    },
    "name": "mautic_get_stats"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Page size. Defaults to 30. Capped by MAUTIC_MAX_LIMIT.
`order`	No
`start`	No	Row offset. Defaults to 0.
`table`	Yes
`where`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 5, 2026

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds little beyond restating the route and parameter names: it does not say which tables are readable, whether access is restricted by MAUTIC_MAX_LIMIT (mentioned only in the schema), or how pagination interacts with more results being available.

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?

Two short, front-loaded sentences with no wasted words. Brevity is a virtue here, though the compression contributes to the missing semantics noted elsewhere.

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

Completeness2/5

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

For a five-parameter tool with a nested filter/sort DSL, no output schema, and 40% schema coverage, this is not enough. An agent cannot construct a valid 'where' expression or know which table names are legal from this definition.

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

Parameters2/5

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

Schema coverage is only 40%: 'table' has no description of valid values, and the order/where item shapes expose col/expr/val with no hint of permitted operators or column names. The description merely recites 'start, limit, order, and where' without adding meaning, so it fails to compensate for the coverage gap.

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: 'Read rows from a stats table', plus the underlying route GET /api/stats/{table}. That is clearer than a tautology, but it never distinguishes this generic stats reader from siblings like mautic_get_email_stats, mautic_get_report, or mautic_list_reports.

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

Usage Guidelines2/5

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

Gives no when-to-use guidance at all. It never says that 'table' must come from mautic_list_stat_tables, nor when an agent should prefer the dedicated email/report stats tools over reading raw table rows.

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

Deploy Server