Rolli MCP

get_agent_schedule

Retrieve a Rolli Agent schedule's full configuration and its 10 most recent execution records by UUID to review setup and recent run history.

Instructions

Get a Rolli Agent schedule's full configuration plus its 10 most recent execution records.

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>"
    },
    "name": "get_agent_schedule"
  }
}

Input Schema

Name	Required	Description	Default
`id`	Yes	Schedule UUID

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.5.0Nov 4, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```

addedInput schema / properties / id / pattern

Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$"

Addedv1.3.0Jun 3, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full burden. It does disclose a real behavioral trait beyond the schema — the result is capped at the 10 most recent execution records — which tells an agent the payload is bounded and not a complete history. It says nothing about read-only safety, auth requirements, error behavior, or whether the 10-record cap is fixed.

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 with no wasted words, and the most decision-relevant information (what the response contains) is front-loaded rather than buried.

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 single-parameter read-only getter with no output schema, the description does the important remaining job by summarizing return contents, including the bounded recent-runs portion. The only real gaps are how the schedule id is discovered and any failure modes, which are minor for a tool this simple.

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 required parameter whose schema coverage is 100% and which is explicitly described as the 'Schedule UUID' with a UUID format and pattern. The description adds no extra meaning about the identifier or its source, so the schema does all the work — the 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?

Names a specific verb and resource ('Get a Rolli Agent schedule') and, unusually, specifies the exact return payload: full configuration plus the 10 most recent execution records. That payload detail distinguishes it from list_agent_schedules and list_agent_schedule_runs, though it never names those siblings 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 only implied: an agent can infer this is the detail-fetch for a single schedule whose UUID it already has, but the description never states when to prefer it over list_agent_schedule_runs or where to obtain the id. No exclusions or prerequisites are given.

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