Skip to main content
Glama
wiresage

MikroTik MCP

by wiresage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_schedulers

Read-onlyIdempotent

Lists scheduled RouterOS tasks with their interval, next run time, and run count so you can verify timers are firing as expected; optionally includes the on-event commands, redacted.

Instructions

Lists the scheduled tasks with their interval, next run and run count.

Notes: name_filter is a substring match. Read next-run together with interval: a scheduler whose run-count is not advancing is firing into a script that errors out, which RouterOS does not surface here — it shows up in the log under the script topic.

`include_source=False` (the default) omits `on-event`, because a
scheduler can carry commands inline, and those routinely hold a bot
token or a password inside a URL. Redaction only recognises labelled
secrets, so withholding the field is what keeps them off the wire. Set
it to True only when you intend to read the commands; the output is
redacted either way, but redaction is pattern-based and is not a
guarantee.

Input Schema

NameRequiredDescriptionDefault
deviceNo
name_filterNo
include_sourceNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.26.1
    • addedInput schema / properties / include_source
      Added value: +{
+  "default": false,
+  "title": "Include Source",
+  "type": "boolean"
+}
  2. Addedv0.25.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond readOnlyHint/idempotentHint, it discloses that on-event can hold inline credentials, that the default omits the field to keep secrets off the wire, and that redaction is pattern-based and therefore not a guarantee. It also warns that a non-advancing run-count failure is not surfaced by the tool but appears under the `script` log topic — exactly the kind of behavior an agent cannot infer from annotations.

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 core behavior is front-loaded in one sentence and the notes are grouped by concern (diagnostics, then secret handling). The closing clause 'the output is redacted either way, but redaction is pattern-based and is not a guarantee' partly restates the preceding sentence, a minor redundancy.

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?

With an output schema present, return values need no explanation, and the description covers the non-obvious risk and diagnostic semantics of schedulers. Only the undocumented `device` parameter keeps it from being fully complete for a three-parameter tool.

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 0%, and the description compensates for two of three parameters well: name_filter is documented as a substring match and include_source as default-False with a security rationale. The `device` parameter is never mentioned in either schema or description, leaving a real gap at 0% coverage.

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 first sentence names a specific verb and resource plus the exact fields returned (interval, next run, run count). It is clearly distinguishable from siblings like list_scripts, which surfaces script bodies rather than scheduling metadata.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete conditions for reading the output (pair next-run with interval to spot a scheduler erroring into its script) and an explicit gate on include_source, telling the agent to leave it False unless commands must be read. It doesn't name an alternative tool when the goal is diagnosing the script itself, which keeps it short of a 5.

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