Skip to main content
Glama
Sign In
SetLuca

SetLuca

Official
by setluca
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List insights

luca_analytics_insights
Read-onlyIdempotent

Retrieve a coach's proactive analytics insights feed—metric drops, spikes, opportunities, risks, and milestones—newest first, with optional status filtering and workspace override.

Instructions

The coach's proactive-insights feed (metric drops/spikes, opportunities, risks, milestones) surfaced by the daily insight-detection cron, newest first. Optionally filter to one status via the status query param (e.g. unread). An empty items list is the honest, expected state for a coach nothing has been flagged for yet — never a fabricated alert.

Luca operation: GET /api/insights Required scopes: analytics:read Required OAuth scope: luca:read; data sensitivity: redacted Does not require idempotency. Use workspaceId or workspaceSlug to override the default workspace configured by environment.

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": "luca_analytics_insights"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo
maxPagesNoMax pages the server auto-fetches and merges (default 10, hard cap 50). If more remain, the result is marked truncated with a nextCursor to continue.
workspaceIdNoOptional Luca workspace id override.
workspaceSlugNoOptional Luca workspace slug override.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral context: the empty-list-is-expected semantics to prevent fabricated alerts, the data source/refresh cadence, required scopes, and 'data sensitivity: redacted'. It does not describe pagination/truncation behavior, which is a minor gap given the maxPages parameter.

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?

The prose portion is front-loaded and efficient, leading with what the feed is and following with the filter and empty-state caveat. The template metadata lines (operation, scopes, idempotency note) add bulk but each carries operational information; the 'Does not require idempotency' line sits awkwardly next to idempotentHint=true.

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 list tool with an output schema, the description covers what the agent most needs: scope requirements, workspace override, ordering, and the honest-empty-state warning. It is essentially complete, with pagination behavior left to the schema.

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 description coverage is 75%, so several params (maxPages, workspaceId, workspaceSlug) are documented in-schema while nested query fields (limit, cursor, status) are not. The description explains the status filter's meaning and the workspace override, adding some value, but says nothing about limit/cursor pagination semantics, so the baseline 3 is right.

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 names a concrete resource (the coach's proactive-insights feed) and lists its content categories (metric drops/spikes, opportunities, risks, milestones) plus its source and ordering (daily cron, newest first). It clearly distinguishes itself from the mutation siblings (mark_read, dismiss, mark_actioned), though it never explicitly names the closest read sibling, luca_insights_unread_count.

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?

It states the optional status filter with an example ('unread') and how to override the default workspace, which is useful invocation context. However, it gives no explicit when-to-use/when-not guidance relative to alternatives such as luca_insights_unread_count or the triage/recommendations tools, leaving selection 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