Skip to main content
Glama

Set the Network Description

set_network_description
Idempotent

Set a Packet Tracer network file's description to document lab objectives, notes, or an IP addressing table in the File > Network description field.

Instructions

Set the network file's description (shown in Packet Tracer under File > Network description / Info). Handy for lab notes, objectives, or an IP addressing table.

Examples:

  • "Describe this lab as 'CCNA 2 - OSPF single area practice'"

  • "Put the addressing table in the network description"

Input Schema

NameRequiredDescriptionDefault
descriptionYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4/5.0
Behavior3/5

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

The annotations already disclose that this is a non-read-only, idempotent, non-destructive write. The description adds where the value is shown and what it is useful for, but it does not explicitly state whether an existing description is overwritten, whether the change persists without save_network_file, or what the response contains.

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 description is front-loaded with the core action and then adds a small set of practical examples. Every sentence contributes useful context without excessive length.

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

Completeness4/5

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

Annotations cover the mutation safety profile and an output schema exists, so return values need not be explained. The main remaining gap is that the description does not mention prerequisites such as having an open network file or whether save_network_file is needed to persist the description.

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

Parameters3/5

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

There is one required string parameter with 0% schema description coverage, so the description carries the burden. It clarifies the intended content through use cases and examples, but it does not describe format, length limits, newline support, or whether the value replaces existing text.

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?

The description states a specific verb and resource: 'Set the network file's description.' It also locates where that value appears in Packet Tracer (File > Network description / Info), which distinguishes this from generic annotation-style tools such as add_text_note.

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?

It gives clear use cases ('lab notes, objectives, or an IP addressing table') and concrete examples, making the intended context obvious. However, it does not explicitly say when not to use it or name alternatives like add_text_note or add_line_annotation.

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