Skip to main content
Glama
Sign In

Mondovo

by com.mondovo.app
OverviewDiscussionsAdmin

List message activity

list_message_activity
Read-onlyIdempotent

Read a site’s sent and scheduled automation message activity. Filter by SMS, email or WhatsApp, contact, or delivery status. Returns only the recipient, safe body preview, provider status/id and safe failure reason; it never returns provider credentials or private journey configuration. Paginated; compare total with limit and offset. To count what was sent in a period ("how many emails did we send yesterday"), pass sent_after / sent_before for that day in the user's timezone (an ISO date-time with its offset, e.g. 2026-10-28T00:00:00+05:30) with status sent and limit 1, and read total: never count a page of messages.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
statusNo
channelNoOnly SMS, email or WhatsApp messages
site_idYesThe site whose message activity to read
user_goalNoOptional: the user's goal behind this call, in one short sentence of plain words (e.g. "add a page so customers can book tables"). No names, emails or other personal details.
contact_idNoOnly messages for this contact
sent_afterNoOnly messages sent on or after this date-time
sent_beforeNoOnly messages sent before this date-time

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / user_goal
      Added value: +{
+  "description": "Optional: the user's goal behind this call, in one short sentence of plain words (e.g. \"add a page so customers can book tables\"). No names, emails or other personal details.",
+  "type": "string"
+}
  2. Changed2 schema fields changed
    • addedInput schema / properties / sent_after
      Added value: +{
+  "description": "Only messages sent on or after this date-time",
+  "format": "date-time",
+  "type": "string"
+}
    • addedInput schema / properties / sent_before
      Added value: +{
+  "description": "Only messages sent before this date-time",
+  "format": "date-time",
+  "type": "string"
+}
  3. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already mark this read-only/idempotent, but the description adds real context: what is returned (recipient, safe body preview, provider status/id, safe failure reason) and what is deliberately never returned (provider credentials, private journey configuration). It also discloses pagination behavior via total/limit/offset, which annotations do not cover.

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?

Front-loaded with purpose, then filters, then return-shape guarantees, then the counting recipe. It is dense and a touch long, but each sentence adds a distinct operational fact; the counting example is verbose yet functional.

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

Completeness5/5

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

There is no output schema, so the description must describe return values — it does, including the safety boundary on what is excluded. With 9 parameters and no output schema, this covers everything an agent needs to call it correctly and interpret `total`.

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

Parameters5/5

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

Schema coverage is only 67%, but the description compensates: it explains that sent_after/sent_before are relative to the user's timezone and must carry an ISO offset (with an example), and that the sent/failed status values map to the delivery lifecycle. It also directs how status and limit interact for counting, which the schema alone does not convey.

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 and resource ('Read a site's sent and scheduled automation message activity') plus the filterable dimensions (channel, contact, delivery status). This is clearly distinct from write-oriented siblings like send_contact_sms or analytics siblings like get_campaign_performance, so an agent can select it without ambiguity.

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

Usage Guidelines5/5

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

Explicitly defines a usage mode beyond simple listing: to count messages sent in a period, pass sent_after/sent_before with status 'sent' and limit 1 and read `total`. It also adds the exclusion 'never count a page of messages,' which prevents a common miscounting pattern.

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

All Mondovo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources