Skip to main content
Glama
Sign In

mcp

by ai.sendraven
OverviewDiscussionsAdmin

list_automation_enrollments

Read-only

The people in one automation, newest enrolment first: each row has the email, status, current_step, next_due_at and, for a cancelled one, cancel_reason. It answers 'is this person still on the sequence?', 'who is waiting on step 2?' and 'why did this sequence stop for them?', which find_contact and list_emails do not. status narrows to one state: 'active' (still going, including people held while the automation is paused), 'completed', 'failed', or 'canceled' for everyone who left early, where cancel_reason says why (unsubscribed, unsubscribed_from_topic, replied, suppressed, exit_tag, required_tag_missing, manual). For the counts alone, list_automations already carries them per status. Any other status is refused with 422 invalid_request, and an unknown automation_id answers 404 not_found. At most 100 per call; while has_more is true, next_cursor passed back as cursor with the same status returns the next page.

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": {
      "automation_id": "<automation_id>"
    },
    "name": "list_automation_enrollments"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoPage size, 1 to 100; defaults to 50
cursorNonext_cursor from the previous page, passed back unchanged
statusNoOnly enrolments in this state; all when omitted
automation_idYesThe automation's id from list_automations (a UUID), not its name or slug

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"Only enrolments in this state; omit for all"New value: +"Only enrolments in this state; all when omitted"
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark this read-only/non-destructive, but the description adds substantial behavioral disclosure the annotations don't carry: the 100-per-call cap, the has_more/next_cursor paging loop with the requirement to pass the same status, and the exact error contract (422 invalid_request for a bad status, 404 not_found for an unknown automation_id). It also discloses that 'active' includes contacts held while the automation is paused — a non-obvious semantic.

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?

Returned fields and the guiding questions are front-loaded, so the agent gets the essentials first. The single dense paragraph is content-rich with essentially no filler, though the enumerated cancel_reason values make it longer than strictly necessary for selection.

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 the return shape, and it does so field by field (email, status, current_step, next_due_at, cancel_reason). Combined with paging, error behavior and status semantics, nothing an agent needs to invoke this correctly is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description meaningfully enriches two parameters: it expands the terse status enum into full semantics per value (including the paused-hold nuance and the cancel_reason vocabulary), and it clarifies the cursor must be replayed with the same status to page correctly. The automation_id constraint (UUID, not name/slug) is duplicated from the schema, which caps the score below 5.

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?

Specific verb (list) plus resource (enrollments in one automation) with an explicit scope clause ('one automation, newest enrolment first') and the returned fields enumerated. It also names two siblings it is not — find_contact and list_emails — so the agent can separate it from the other list tools without opening a schema.

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?

States the three concrete questions it answers ('is this person still on the sequence?', 'who is waiting on step 2?', 'why did this sequence stop?') and routes the agent elsewhere for counts ('list_automations already carries them per status'). Both when-to-use and when-to-use-something-else are covered.

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

All mcp 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