fritz-mesh-mcp

by gr9driver

Overview Schema Source Related Servers Discussions Admin

Python

Local

fritz_wake_on_lan

Sends a Wake-on-LAN packet through the FRITZ!Box master to power on a networked device by its MAC address.

Instructions

Ask the master to send a Wake-on-LAN packet.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mac_address": "<mac_address>"
    },
    "name": "fritz_wake_on_lan"
  }
}

Input Schema

Name	Required	Description	Default
`mac_address`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 2, 2026

TDQS

C2.5/5.0

Behavior2/5

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

No annotations, so the description carries the full burden. It hints that the FRITZ!Box master issues the packet, but says nothing about whether the target MAC must already be known to the router, whether the packet is broadcast to the subnet, what response to expect, or that the machine may not wake if WoL is disabled.

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?

One short sentence with no filler, so nothing is wasted, but the brevity is under-specification rather than economy — the single sentence does not earn its place by covering the essentials.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A mutation-style action with no annotations, no output schema, and a completely undocumented required parameter. For a tool whose only input format is easy to get wrong, this leaves too much for the agent to guess.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single required parameter has 0% schema description coverage, and the description never mentions mac_address at all. Format guidance (colon-separated vs. hyphenated vs. bare hex) is exactly the kind of ambiguity that matters here and is absent from both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("send a Wake-on-LAN packet") and is clearly distinct from every sibling, which are all status/config tools. However, "ask the master" is FRITZ-specific jargon that leaves it slightly ambiguous which device originates the packet.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No indication of when to use this rather than e.g. fritz_get_device or fritz_list_devices, and no prerequisites such as the device needing to be registered or WoL enabled in BIOS/OS. The agent must infer the use case entirely.

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