Skip to main content
Glama

logs

Retrieve recent RouterOS log entries with optional topic filtering. Limits results to a specified number of entries.

Instructions

Read recent RouterOS log entries (most recent last).

limit must be positive and is capped at 500. topics, if given, is matched as a plain substring against each entry's topics field - no regex, no unbounded scans - and is applied BEFORE the limit cut: the full log is filtered by topics first, then the last limit matching entries are returned (not the last limit raw entries, then filtered - that would silently drop matches).

R1: this reads the whole /log table via librouteros' path().select() and slices in Python rather than asking RouterOS for only the last limit rows. librouteros' structured API doesn't expose a clean "give me only the tail" query for /log (RouterOS's own count-only print flags aren't reachable through path().select() the way a .limit()/offset would be), so a "request fewer rows" optimization here would mean building a fragile ad-hoc workaround for a table that is small in practice (a few hundred to low thousands of rows on RouterOS's own ring buffer). Left as-is; revisit if a real device turns out to have a much larger log buffer than expected.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
topicsNo
device_nameYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior5/5

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

No annotations are provided, so the description fully discloses behavior: it reads the entire /log table, applies topics filter before limit, returns most recent last, and explains the lack of optimization. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The first sentence clearly states the purpose, but the description includes an internal implementation note (R1) that is verbose and may not be necessary for an AI agent to use the tool correctly.

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?

Given the 3 parameters, no schema descriptions, and presence of an output schema, the description adequately explains the behavior for limit and topics. However, it does not cover prerequisites or potential errors, and device_name is not discussed.

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 has no parameter descriptions (0% coverage). The description adds meaning for 'limit' (positive, capped at 500) and 'topics' (plain substring, applied before limit), but does not elaborate on 'device_name' beyond it being required.

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 tool reads recent RouterOS log entries with the most recent last. The verb 'Read' and resource 'RouterOS log entries' are specific, and the sibling tools are distinct (interfaces, ping, etc.), so no confusion.

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 does not explicitly state when to use this tool versus alternatives. It provides constraints (limit cap, substring matching) and implementation details, but lacks guidance on when not to use it or how it compares to other tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/thalisantunes/mcp-mikrotik'

If you have feedback or need assistance with the MCP directory API, please join our Discord server