Retrieves known FRITZ!Box devices with IP, MAC, active/inactive status, and connection type; filter by name, limit results, or show only active devices.
Bekannte Geräte der Box mit IP, MAC, aktiv/inaktiv, Anschlussart.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| limit | No | ||
| nur_aktive | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only weakly implies a read-only inventory operation. It does not clarify whether device state is live or cached, whether inactive devices are included by default, or whether results can be truncated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single compact phrase is easy to scan and puts the resource and principal data fields first, with no filler. Its brevity is efficient, although it leaves several operationally useful details unstated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema reduces the need to document return fields, and the tool itself is relatively simple. Nevertheless, the complete absence of parameter documentation, behavioral context, and sibling differentiation leaves substantial gaps for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters. In particular, it never states that name filters devices, nur_aktive restricts results to active devices, or limit caps the result count; the mention of aktiv/inaktiv describes device data rather than filter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies an inventory of known devices on the box and specifies IP, MAC, active/inactive state, and connection type as the available data. It does not explicitly state a listing verb or differentiate this overview from the sibling tools geraet and mesh_uebersicht.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implicitly suggested when an agent needs an overview of known network devices and their connection details. There is no explicit guidance on when to choose hosts over geraet for an individual device or mesh_uebersicht for mesh topology.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.