Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Read an enrollment timeline

luca_campaigns_enrollments_timeline
Read-onlyIdempotent

Retrieve the full timeline for a campaign enrollment to see every message sent, its timestamp, and how the lead responded. Use it to audit follow-up history or troubleshoot a prospect's journey.

Instructions

Read every step one enrollment has been through: what got sent, when, and how the lead responded.

Luca operation: GET /api/campaigns/{id}/enrollments/{enrollmentId}/timeline Required scopes: campaigns:read Required OAuth scope: luca:read; data sensitivity: full_content Does not require idempotency. Use workspaceId or workspaceSlug to override the default workspace configured by environment.

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": {
      "id": "<id>",
      "enrollmentId": "<enrollmentId>"
    },
    "name": "luca_campaigns_enrollments_timeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
workspaceIdNoOptional Luca workspace id override.
enrollmentIdYes
workspaceSlugNoOptional Luca workspace slug override.

Output Schema

NameRequiredDescriptionDefault
resultYes
provenanceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.2
    • addedOutput schema / properties / result / properties / enrollment / properties / keptParkedByCoach
      Added value: +{
+  "type": "boolean"
+}
  2. First observedv0.4.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, yet the description adds genuinely new context: required scopes (campaigns:read, luca:read), full-content data sensitivity, and the note that idempotency is not required. This is exactly the auth/sensitivity disclosure annotations cannot carry, though it says nothing about pagination or timeline size limits.

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?

A single purpose sentence followed by terse operational metadata (endpoint, scopes, sensitivity, idempotency, workspace override). Every line conveys distinct information with no padding, and the core purpose is front-loaded.

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

Completeness4/5

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

For a read-only lookup with an existing output schema, the description covers purpose, endpoint, scopes, sensitivity and the workspace override, so an agent has what it needs to invoke it correctly. The remaining gap is the unexplained 'id' parameter, which is left entirely to the schema's UUID constraint.

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 50%: workspaceId and workspaceSlug are documented in the schema, while id and enrollmentId carry no descriptions. The description clarifies workspace override behavior and frames enrollmentId as 'one enrollment', but it does not explain what id refers to (campaign vs enrollment parent), leaving a real ambiguity unaddressed.

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 opening sentence gives a specific verb and resource ('Read every step one enrollment has been through') and even enumerates the returned content (what was sent, when, how the lead responded). It is clearly distinguishable from sibling list/resume operations by scoping to a single enrollment, though it does not name an alternative sibling explicitly.

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?

Usage is implied — call this when you need the per-enrollment history rather than a campaign-wide list — but there is no explicit when-to-use/when-not statement and no reference to the sibling enrollments_list or enrollments_resume tools. The only concrete guidance is about workspace override, which is parameter-level rather than tool-selection-level.

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