Skip to main content
Glama
Sign In
MikroTik MCP

MikroTik MCP

by wiresage
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_netwatch

Read-onlyIdempotent

Lists the netwatch probes with their live status and measurements.

Instructions

Lists the netwatch probes with their live status and measurements.

Configuration first, then a LIVE STATE block with status, since — the timestamp of the last transition — and, on an ICMP probe, the last test's numbers: rtt-avg, loss-percent, failed-tests. Match the two blocks by host, or by the .id the live one carries.

Notes: host_filter and comment_filter are substring matches; status_filter and type_filter are exact. Pass status_filter="down" to list only what is currently failing.

`include_source=False` (the default) omits `up-script`,
`down-script` and `test-script`, because a probe that alerts through a
webhook or an e-mail carries the token or the password inline. Set it
to True only when you intend to read those commands; the output is
redacted either way, but redaction is pattern-based and is not a
guarantee.

A probe with no `src-address` follows whichever WAN is active, so it
keeps reporting across a failover; one pinned to a source address
reports that path only. Which of the two you want depends on whether
you are watching the internet or a specific link.

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

Input Schema

NameRequiredDescriptionDefault
deviceNo
host_filterNo
type_filterNo
status_filterNo
comment_filterNo
include_sourceNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.25.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already establish that this is a read-only, idempotent, non-open-world operation, but the description adds substantial behavioral context: the live-state fields returned, ICMP measurement fields, the redaction caveat for script-bearing probes, and failover behavior for probes without `src-address`. This is meaningful disclosure beyond the structured annotations.

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 front-loaded with the core purpose, then structured into output-shape, filtering, security, and source-address notes. Despite its length, every section contributes operational meaning and there is no filler.

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?

An output schema exists, so return-value documentation is not strictly required, yet the description still explains the two returned blocks and key fields. Combined with the filter semantics and source-address caveat, it gives an agent enough context to call and interpret the tool correctly; the omitted `device` explanation is minor.

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?

Schema description coverage is 0%, so the description carries most of the burden. It explains that `host_filter` and `comment_filter` are substring matches while `status_filter` and `type_filter` are exact, gives an example for `status_filter`, and documents `include_source` default/security behavior; only the `device` parameter is not discussed.

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 states a specific verb and resource: it lists netwatch probes and returns both configuration and live status/measurement data. It also explains the two output blocks and how to match them, so an agent can immediately understand what the tool is for.

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 clear when-to-use guidance for `status_filter="down"` and for setting `include_source=True` only when source commands must be read. It also explains the source-address tradeoff for failover monitoring, though it does not name alternative sibling tools or explicitly say when not to use this listing tool.

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