MikroTik MCP

Overview Schema Source Related Servers Discussions Admin

get_ipsec_installed_sa

Read-onlyIdempotent

Lists installed IPsec child/phase 2 security associations and their flags to distinguish SAs carrying traffic from those only installed.

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 substring matches on the SA endpoints, which are the tunnel endpoints (public addresses), not the encapsulated subnets. Behind NAT-T the endpoints carry the port (198.51.100.2:4500), which is why this is not an exact match: filtering on the bare address would find nothing there and report no SAs while some exist.

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

Input Schema

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

Output 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

Behavior5/5

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

Annotations only declare readOnly, idempotent, and closed-world behavior, while the description adds substantial operational context: the meaning of S/H/E flags, that a missing S can mean idle rather than broken, and that per-SA counters do not map cleanly to policies once multiple child SAs exist. This is exactly the kind of behavioral nuance an agent needs beyond 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 description is long but front-loaded with the core purpose and the key interpretive insight about the S flag. The bullet structure for pitfalls and the notes section are readable, and most sentences earn their place, though the overall length is greater than strictly necessary.

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 the description need not explain return values. It is complete on interpretation and address-filter behavior, but leaves the device parameter and explicit sibling comparisons unaddressed.

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 description coverage is 0%, so the description carries the burden of explaining parameters. It does clarify that address filters are substring matches on tunnel endpoints, including NAT-T port forms like 198.51.100.2:4500, which is valuable and compensates for the src/dst filter parameters. It says nothing about the device parameter, so one of three parameters remains undocumented.

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: 'Lists the installed IPsec security associations (child/phase 2 SAs).' It distinguishes the tool from sibling resources such as active peers, policies, and proposals by scoping to installed child/phase 2 SAs.

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 diagnostic use by saying 'The Flags legend is the point of this view' and by explaining what the output does not tell you. However, it never explicitly names alternatives such as get_ipsec_active_peers or list_ipsec_policies or states when to use one over the other, leaving selection to inference.

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

Deploy Server