Skip to main content
Glama
Sign In
@kieksme/listmonk-mcp

@kieksme/listmonk-mcp

by kieksme
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Dashboard Charts

listmonk_get_dashboard_charts
Read-onlyIdempotent

Retrieve Listmonk dashboard time-series chart data, including subscriber growth and campaign views, to analyze trends and monitor campaign performance.

Instructions

Returns time-series chart data (subscriber growth, campaign views) shown on the Listmonk dashboard.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "listmonk_get_dashboard_charts"
  }
}

Input Schema

NameRequiredDescriptionDefault
response_formatNoOutput format: 'markdown' for human-readable text (default) or 'json' for machine-readable data.markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered externally. The description adds useful content context by naming the two metric families returned, but discloses nothing about the time window, granularity, or aggregation behavior of the series, which is the main behavioral unknown for a chart tool.

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

Conciseness5/5

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

One sentence, front-loaded with the return type, with the parenthetical metrics earning their place by specifying payload contents. No filler, no restatement of the tool name.

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 zero-required-parameter, single-schema-property tool with no output schema, the description identifies the returned metric families but not the shape of the series (timestamps? per-campaign breakdown? fixed time window?). Given no output schema exists, slightly more return-shape detail would help an agent decide whether to parse JSON or markdown.

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?

There is a single optional parameter (response_format) with 100% schema description coverage and an enum with a documented default, so the schema fully carries parameter meaning. The description adds nothing about output format beyond what the schema states; baseline 3 applies.

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

Purpose4/5

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

The description gives a specific verb ('Returns') and resource ('time-series chart data'), and names the concrete metrics (subscriber growth, campaign views) so an agent knows exactly what payload to expect. It implicitly distinguishes itself from listmonk_get_dashboard_counts by promising chart series rather than counts, though it never names that sibling.

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

Usage Guidelines3/5

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

There is no explicit when-to-use or when-not-to-use statement and no reference to the adjacent listmonk_get_dashboard_counts tool. Usage is only implied by the phrase 'shown on the Listmonk dashboard', which is enough for an agent to infer this is for dashboard visualization data but leaves the counts-vs-charts choice to inference.

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