netmiko-mcp-linksys

Overview Schema Source Related Servers Discussions Admin

snmp_write_view_create

Adds one writable column to an SNMP write view, enabling community write access to permitted columns; configuration is not saved.

Instructions

Add one writable column to an SNMP write view. Does not save.

Gate this in the hub with unlock. subtree must be ifAdminStatus (1.3.6.1.2.1.2.2.1.7), ifAlias (1.3.6.1.2.1.31.1.1.1.18) or pethPsePortAdminEnable (1.3.6.1.2.1.105.1.1.1.3, PoE on/off); whole MIB subtrees are never allowed in a write view. There are no per-port exclusions: anyone with a community bound to this view can write these columns for every port, including SWITCH_PROTECTED_PORTS. The command is sent with a "%" error check and verified in show snmp viewtree; on any failure the column is removed again (no snmp view <view> <oid>) and the viewtree must equal the state before. The CLI syntax is not live-confirmed.

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": {
      "view_name": "<view_name>",
      "subtree": "<subtree>"
    },
    "name": "snmp_write_view_create"
  }
}

Input Schema

Name	Required	Description	Default
`subtree`	Yes
`view_name`	Yes

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.2.0Nov 14, 2026

TDQS

A4.2/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and delivers: it is a mutation, it is not persisted, it requires unlock gating, writes affect every port including SWITCH_PROTECTED_PORTS, and it rolls back the column on any failure via 'no snmp view <view> <oid>' with a viewtree equality check. It even flags that CLI syntax is not live-confirmed, which is unusually candid risk disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads purpose and the 'Does not save' caveat, then layers constraints and failure semantics in a logical order. It is dense but each sentence, including the OID parentheticals, carries operational information; only minor tightening is possible.

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?

An output schema exists, so return values need not be explained, and the description covers prerequisites, safety impact, rollback, and verification. The only material omission is guidance on view_name semantics (must an existing view be created first, and which tool does that).

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate, and it does for subtree by naming the exact three allowed OIDs (ifAdminStatus, ifAlias, pethPsePortAdminEnable) and excluding whole MIB subtrees. view_name is left unexplained (e.g., whether the view must pre-exist), which is the remaining gap.

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?

Opens with a specific verb+resource: 'Add one writable column to an SNMP write view,' which implicitly separates it from snmp_view_create (which creates the view itself). The purpose is unambiguous, though no sibling is named explicitly, so an agent must infer the boundary with snmp_view_create.

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?

Gives a concrete prerequisite ('Gate this in the hub with unlock') and states 'Does not save,' implying save_config is a follow-up step. It also constrains when the tool is applicable by enumerating the only permitted subtree values, but never explicitly contrasts itself with snmp_view_create or names the follow-up save tool.

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

Deploy Server