Skip to main content
Glama
figranium

Figranium MCP Server

Official

schedule_list

Read-onlyIdempotent

List all automation tasks that have schedules configured, including disabled ones, to review or manage scheduled runs.

Instructions

List all tasks that have schedules configured (enabled or not).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety profile. The description adds that it includes schedules regardless of enabled state, which is useful context. However, it does not disclose output format, pagination, or any other behavioral traits beyond the given, so it does not exceed the baseline for annotation-backed transparency.

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?

The description is a single, concise sentence that is front-loaded with the action ('List') and subject ('all tasks that have schedules'). It includes the 'enabled or not' qualifier compactly. There is no fluff, making it highly efficient.

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?

This is a simple, parameterless list operation. The description fully explains its scope and includes the important nuance about enabled/disabled states. There is no output schema, but the description suffices for an agent to know what to expect. The presence of siblings does not create a need for more information because the purpose is clear.

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?

With zero parameters and 100% schema coverage (empty schema), the baseline is 4 per rubric. The description adds nothing about parameters because there are none, but this matches the baseline exactly.

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?

The description clearly states the verb 'List' and the resource 'all tasks that have schedules configured', with an explicit qualifier '(enabled or not)' that disambiguates from potentially similar tools. This makes the tool's purpose unambiguous and distinct from siblings like schedule_get_all_status or schedule_get_status, which focus on status rather than the task list.

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?

The description implies usage when one needs to know which tasks have schedules, but it does not explicitly mention when to use this over schedule_get_all_status or schedule_get_status. The differentiation is implicit from the wording, but there is no direct guidance, so it earns a 3 rather than a 4 or 5.

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