MikroTik MCP

Overview Schema Source Related Servers Discussions Admin

get_ipsec_installed_sa

Read-onlyIdempotent

List installed IPsec security associations (child/phase 2 SAs) on MikroTik RouterOS and check the S flag to identify SAs carrying traffic.

Instructions

Lists the installed IPsec security associations (child/phase 2 SAs).

The Flags legend is the point of this view. On RouterOS 7 it reads:

S - SEEN-TRAFFIC  the SA has carried packets
H - HW-AEAD       the cipher is running in hardware
E - ESP

S is the only field that separates an SA carrying traffic from one that is merely installed. A remote end reporting the connection as up, or its own byte counters growing, does not contradict a missing S: those count what the far side sent, not what arrived.

Two things this does NOT tell you, both easy to get wrong:

A missing S can mean idle, not broken. An SA nothing has used looks exactly like one that is failing, and RouterOS withholds addtime and expires-in until traffic appears, which makes it look half installed. Put traffic over the selector before concluding anything.
Per-SA counters do not map onto policies once a peer has several child SAs. Traffic picks among them, so one SA can carry the outbound side of two policies while another sits frozen at the counter it had minutes after install. Pairing SAs by hand — by install time, by address, by lifetime — invents a structure that is not there. Watch which counters move under traffic you control instead.

Notes: Address filters are exact matches on the SA endpoints, which are the tunnel endpoints (public addresses), not the encapsulated subnets.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`device`	No
`dst_address_filter`	No
`src_address_filter`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.25.0Oct 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description goes well beyond them by disclosing that a missing 'S' flag can mean idle rather than broken, that RouterOS withholds addtime/expires-in until traffic appears, and that per-SA counters do not map onto policies with multiple child SAs — genuinely useful operational context, though it is output-interpretation rather than side-effect disclosure.

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 first sentence front-loads the purpose, and the remainder is organized into a legend block and labeled caveat bullets, so density is well managed. It is nonetheless a heavy read for a read-only list tool, with several sentences devoted to output interpretation that could arguably live in output documentation, keeping it below a 5.

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?

An output schema exists, so raw return shape need not be documented, yet the description supplies the interpretive context (flag legend, idle-vs-broken, counter non-mapping, filter semantics) that makes this complex diagnostic tool usable. The only real gap is the undocumented 'device' parameter, which leaves it slightly short of fully complete.

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 bears the burden, and it delivers a precise, non-obvious clarification for the two filter params: address filters are exact matches on the tunnel (public) endpoints, not the encapsulated subnets. This is real meaning the schema cannot convey. The 'device' parameter remains undocumented, which keeps it short of a 5.

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?

States a specific verb and resource ('Lists the installed IPsec security associations') and disambiguates with the parenthetical '(child/phase 2 SAs)', which separates it from the peer-, policy-, proposal- and profile-listing siblings. An agent can immediately tell this returns live SA state rather than configuration objects.

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 gives strong interpretive guidance for how to read the results and warns about two misreading pitfalls, but it never states when to prefer this tool over siblings such as get_ipsec_active_peers or list_ipsec_policies, nor does it name any alternative or prerequisite. Usage is only implied (troubleshooting whether a child SA is actually passing traffic).

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

Deploy Server