Skip to main content
Glama
tplink-deco-mcp-server

tplink-deco-mcp-server

by roquerodrigo

System log

get_system_log
Read-only

Reads router system log pages to diagnose outages, PPPoE reconnects, reboots, DHCP, and Wi-Fi events, returning entries, page count, and severity filters.

Instructions

Read one page of the router's system log, newest page by default.

Returns up to 100 lines from oldest to newest (time, syslog facility and level, the process that wrote it, message), the page count, and the severities that can be passed as severity. Use it to explain outages, PPPoE reconnects, reboots, DHCP or Wi-Fi events. The newest page can hold only a few lines, so read the page before it when more context is needed. The router keeps a limited buffer, so older history may already be gone.

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_system_log"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoZero-based page of 100 lines; 0 is the oldest. Omit for the newest page; lower numbers go back in time.
severityNoMinimum severity, a `value` from `available_severities` of an earlier result. Omit for NOTICE and worse.

Output Schema

NameRequiredDescriptionDefault
pageYesZero-based page index; 0 is the oldest page.
entriesYesLines from oldest to newest.
severityYesMinimum severity this page was filtered on.
total_pagesYesNumber of pages; the last one holds the newest lines.
available_severitiesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only cover readOnlyHint/openWorldHint; the description adds the substantive behavior: line cap of 100, intra-page ordering oldest to newest, the fields in each line, the returned page count and severity vocabulary, and that the router's limited buffer can lose older history. That last point is critical for an agent reasoning about missing data.

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 identification and default come first, then return shape, then use cases, then the paging caveat and retention caveat. Every sentence carries operational information; nothing is redundant 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?

Covers purpose, default behavior, return shape, filtering vocabulary, paging strategy, and retention limits. With an output schema present and full schema coverage, nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so baseline is 3, but the description adds meaning: the default is the newest page, pages are 100 lines, and 'severity' values come from the severities the response exposes. It also warns that the newest page may be short, which explains an otherwise confusing result for `page` omission.

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 ('Read one page of the router's system log') plus the default page selection, and it is clearly distinct from every sibling tool (none of which touch logs). An agent can select it without opening the schema.

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?

Gives concrete diagnostic scenarios ('explain outages, PPPoE reconnects, reboots, DHCP or Wi-Fi events') and paging guidance ('read the page before it when more context is needed'). There are no competing siblings to exclude, but no explicit 'do not use for X' is stated.

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