Find MikroTik routers on the local network via MNDP, similar to Winbox Neighbors, to audit or configure them.
Find MikroTik devices on the local network via MNDP (like Winbox Neighbors).
| Name | Required | Description | Default |
|---|---|---|---|
| seconds | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only, time-bounded multicast probe (MNDP), but does not state that it blocks for a dwell period, that it requires multicast-capable local network access, or whether it disrupts anything. Key behavioral facts are left unstated.
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?
One tight sentence, zero waste, with the mechanism and the familiar Winbox analogy front-loaded. Nothing to trim.
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?
Return values are covered by the output schema, so the description needn't describe results. However, for a network-discovery probe with no annotations, the absence of timeout behavior and network preconditions leaves the definition only minimally complete.
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 coverage is 0% and the single parameter 'seconds' (default 5) is never mentioned in the description. The title alone hints it is a duration, but the description does not explain that it controls how long discovery listens, which matters for latency expectations.
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?
States a specific verb (Find), resource (MikroTik devices), scope (local network) and mechanism (MNDP, with a Winbox Neighbors analogy). No sibling tool performs discovery, so an agent can distinguish it readily, though the description never explicitly contrasts itself with siblings like connect or list_sessions.
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?
No guidance on when to use discovery versus alternatives, nor any prerequisite such as needing to be on the same L2 network before calling connect or reconnect. Usage is only inferable from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.