get_networkRetrieves agents and their connections, including edge type, count, and timestamps, so you can inspect the current agent network and its activity.
Agents on this machine and the edges between them. Each edge is {from, to, kind, count, first_ts, last_ts}, counted over the retention window. Test events are left out. At most 200 edges, newest first.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: counting over a retention window, exclusion of test events, a hard cap of 200 edges, and newest-first ordering – all things an agent could not infer from annotations or an empty schema.
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?
Four short sentences with no filler; the core subject is front-loaded and the constraints follow in decreasing importance. The fragmentary opening sentence is slightly abrupt but not wasteful.
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?
With no output schema, the description carries the return-shape burden and does so for edges (from, to, kind, count, first_ts, last_ts). The node/agent shape is left unexplained, and there is no note on cost or typical result size beyond the 200-edge cap.
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?
There are zero parameters, so the baseline is 4 and there is nothing parameter-related to mislead. Useful compensating detail is supplied about the result shape instead.
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 states specifically what is returned: agents on this machine plus the edges between them, with the edge shape spelled out. It is clearly a graph-snapshot read rather than an event query, though the opening is a noun phrase with no explicit verb.
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 only implied by the resource described; there is no statement of when to reach for this versus list_events or report_event. The scoping notes (retention window, test events excluded) describe what the data covers, not when to call the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.