Skip to main content
Glama
acato

snmp-mcp

by acato
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

snmp-mcp

An MCP server that wraps the IETF SNMP standard so AI agents (Claude Code, Claude Desktop, IDE assistants) can poll any SNMP-speaking device on the network without rediscovering each MIB's quirks on every task.

Status: beta. Feature-complete v0 — 9 tools (4 generic primitives, 5 MIB-specific convenience wrappers) covering read-only inspection across switches, routers, printers, and host-resources targets. 66 unit tests + 9 live integration tests passing against two device classes (a managed RouterOS switch and an Epson print server with full PRINTER-MIB support). API is stable. See DESIGN.md for the full architecture, tool surface, and MIB-to-tool mapping.

Why

Mixed-vendor networks need a vendor-neutral read-side abstraction:

  • A managed switch (MikroTik, Cisco, Aruba, Omada) exposes interface counters via IF-MIB. Use HC counters (ifHCInOctets/ifHCOutOctets) on any link >=1 Gbps — the 32-bit ifInOctets/ifOutOctets saturate at ~4.29 Gbps.

  • A network printer (HP, Brother, Canon, OKI, Epson) exposes toner / ink / drum levels via PRINTER-MIB (RFC 3805). The MIB is identical across vendors; the wrapper returns one schema for all of them.

  • A Linux host running net-snmp exposes CPU, memory, and disk via HOST-RESOURCES-MIB (RFC 2790). Same wrapper, same schema.

  • Generic SNMP get/walk/bulkwalk/table primitives are also exposed so you can talk to anything else without writing vendor-specific code paths.

snmp-mcp is the read-side counterpart to vendor-specific MCPs that already handle writes for one device (e.g., synology-mcp for DSM).

Related MCP server: Device MCP Server

Scope

MVP (v0)

Generic primitives (4):

  1. snmp_get — fetch one or more OIDs (numeric or symbolic).

  2. snmp_walk — walk a subtree via GETNEXT.

  3. snmp_bulk_walk — walk a subtree via GETBULK (faster for large tables).

  4. snmp_table — fetch and tabularize an SNMP table.

MIB-specific convenience wrappers (5):

  1. system_info — SNMPv2-MIB::system group (sysDescr / sysName / sysLocation / sysUpTime / ...).

  2. interfaces_list — IF-MIB::ifTable + IF-MIB::ifXTable, with HC counters preferred where exposed.

  3. host_resources — HOST-RESOURCES-MIB (CPU load, memory, storage).

  4. printer_status — PRINTER-MIB (supplies, trays, alerts, status).

  5. device_detect — probe sysObjectID + a handful of well-known root OIDs to report which standard MIBs the device supports.

Out of scope (v0)

  • SNMP SET (writes). Read-only by design.

  • SNMP trap receiver (long-running daemon, different process model).

  • Loading random vendor MIBs at runtime — standard IETF MIBs only.

  • MIB browser GUI. Stick to the programmatic tool surface.

  • Custom polling schedules or time-series storage. That belongs in Home Assistant, Prometheus, or similar.

See DESIGN.md §11 for rationale.

Multi-host

Every tool accepts a host parameter. Credentials and connection settings come from a config file or environment variables — there are no hardcoded hosts in this codebase. See examples/config.toml.

Quickstart

# Install from PyPI (when published)
uv tool install snmp-mcp

# Or run from source
git clone https://github.com/acato/snmp-mcp
cd snmp-mcp
uv sync
uv run snmp-mcp

Windows: avoid Microsoft Store Python

If uv picks Microsoft Store Python (path under \WindowsApps\PythonSoftwareFoundation...) when creating the venv, the MCP runs fine from a terminal but fails to launch from GUI hosts like the Claude desktop app, IDE extensions, or scheduled tasks. You will see:

Unable to create process using "...\WindowsApps\PythonSoftwareFoundation.Python.3.12_...\python.exe"

The Store-Python app-execution alias requires an interactive user context that GUI-spawned children do not get. Pin uv to a non-Store interpreter — uv's managed Python is easiest:

uv python install 3.12
uv venv --python 3.12 --python-preference only-managed --clear
uv sync

Verify: Get-Content .venv\pyvenv.cfg — the home = line should point under AppData\Roaming\uv\python\..., not \WindowsApps\. A python.org installer or winget install Python.Python.3.12 also works.

Wire into Claude Code

claude mcp add snmp-mcp -- uv run --directory /path/to/snmp-mcp snmp-mcp

Configuration

Copy examples/config.toml to ~/.config/snmp-mcp/config.toml and fill in your hosts. Or set per-host env vars (see DESIGN.md §6).

Compatibility

  • SNMPv1 — supported (legacy devices).

  • SNMPv2c — first-class target (community-based; most common).

  • SNMPv3 — supported with auth (MD5/SHA/SHA2-family) and priv (DES/3DES/AES128/192/256).

License

Apache License 2.0. See NOTICE for attributions.

Trademarks

This project is not affiliated with, endorsed by, or sponsored by any vendor whose devices it polls.

Available Tools

9 tools
device_detectA

Probe which standard MIBs a device implements. Issues 5 GETs (sysObjectID, sysDescr, ifNumber, hrSystemUptime, prtGeneralPrinterStatus.1.1) and reports a vendor hint (decoded from the sysObjectID enterprise number) plus a list of supported_mibs. Useful as a smoke test before calling heavier tools.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes

TDQS

A3.8/5.0
Behavior4/5

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

Despite no annotations, the description details the exact 5 GETs performed (sysObjectID, sysDescr, etc.) and explains the output (vendor hint, supported_mibs). This provides sufficient behavioral context for safe invocation.

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?

Description is two sentences, each earning its place: first states purpose and action, second provides usage guidance. No redundant information.

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

Completeness3/5

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

Given low complexity (1 param, no output schema), the description adequately explains the tool's function and behavior but fails to document the single parameter 'host'. This gap reduces completeness.

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

Parameters1/5

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

The schema has 1 parameter 'host' with 0% description coverage, and the tool description does not explain what 'host' represents (e.g., IP address, hostname). No additional meaning is provided beyond the field name.

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?

Description clearly states the tool probes which standard MIBs a device implements by issuing 5 specific GETs. It explicitly distinguishes itself from sibling tools as a lightweight smoke test before heavier tools.

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?

Explicitly recommends use as a smoke test before heavier tools, providing clear context for when to use it. However, it does not include when-not-to-use scenarios or explicit alternatives beyond the sibling list.

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

host_resourcesA

HOST-RESOURCES-MIB (RFC 2790) summary: CPU load per core (hrProcessorLoad), memory (hrMemorySize + derived swap), uptime, process count, and storage table (filesystems + RAM + swap). Raises 'unsupported' if the agent does not implement the MIB at all (typical on bare network switches).

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses that the tool raises an 'unsupported' error for agents lacking the MIB, which is critical behavioral insight. It does not detail side effects or authentication, but for a read-only query, the disclosure is adequate.

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 a single, front-loaded sentence that efficiently conveys the tool's purpose and a key behavioral note. No extraneous words; every part earns its place.

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?

Given the single parameter and lack of output schema, the description sufficiently outlines the returned data categories and an error condition. It could be slightly improved by noting return format, but overall it provides necessary context.

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

Parameters1/5

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

The schema has 0% description coverage and only a single 'host' parameter. The description does not elaborate on the parameter's meaning, format, or constraints, leaving the agent with no additional guidance beyond the schema's bare type.

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 explicitly states it provides a summary of HOST-RESOURCES-MIB data, listing specific metrics (CPU, memory, uptime, process count, storage table). It distinguishes itself from sibling tools like system_info by referencing a specific MIB and detailing the error case for unsupported agents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions a failure mode for uncooperative devices (bare switches), giving some usage context. However, it does not explicitly state when to use this tool over siblings like system_info or interfaces_list, leaving the agent to infer applicability.

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

interfaces_listA

List network interfaces via IF-MIB (RFC 2863). Merges ifTable + ifXTable per ifIndex. HC counters (ifHCInOctets / ifHCOutOctets) are returned alongside 32-bit counters. ifSpeed saturation at ~4.29 Gbps is handled automatically — ifSpeed_bps falls back to ifHighSpeed*1e6 with ifSpeed_source='ifHighSpeed' and a warning.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes

TDQS

A3.6/5.0
Behavior4/5

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

With no annotations, the description effectively communicates behavioral traits: merging of ifTable and ifXTable, handling of high-capacity counters, and automatic ifSpeed fallback. It fails to disclose if the tool has side effects or requires specific permissions, but for a read-only list operation, this is adequate.

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 concise and well-structured, starting with the core purpose and then adding technical details. No redundant information is present, and every sentence adds value.

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

Completeness3/5

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

While the description covers the tool's operation and key behaviors, it lacks information about the output format (since no output schema is provided) and does not explain the 'host' parameter. For a simple one-parameter tool, these gaps are noticeable but not critical.

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

Parameters2/5

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

The input schema has 0% description coverage and the single 'host' parameter has no explanation. The description does not clarify whether 'host' expects an IP address, hostname, or includes SNMP community details, leaving the agent to infer from context.

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 clearly states the tool lists network interfaces via IF-MIB (RFC 2863), providing a specific verb and resource. It also explains the merging of tables, which distinguishes it from sibling tools like snmp_table or snmp_walk that may not have this specific logic.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not mention when to use this tool versus alternatives. There is no guidance on prerequisites, such as SNMP credentials, or situations where other tools like snmp_get or device_detect might be more appropriate.

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

printer_statusC

PRINTER-MIB (RFC 3805) status: supplies (toner / ink / drum levels with percent computed when capacity is known), input trays, output bins, and active alerts. Works across HP, Brother, Canon, OKI, Epson, Lexmark. Sentinel values (-2 unknown, -3 not measured) are handled per RFC 3805.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes

TDQS

C2.9/5.0
Behavior2/5

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

No annotations exist, so description carries full burden. It discloses supported brands and sentinel value handling but omits critical behaviors: required SNMP version/community, read-only nature, error handling (unreachable host), or potential side effects.

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?

Description is concise with three sentences, front-loading main purpose and supported brands. No redundant information, though could benefit from structured details about parameters.

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

Completeness3/5

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

Covers reported components (supplies, trays, bins, alerts) and sentinel value handling, which aids understanding. However, lacks behavioral context (e.g., authentication, timeout) and does not describe return format despite missing output schema.

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

Parameters1/5

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

Schema has one required parameter 'host' with no description coverage (0%). The tool description does not explain the parameter's format (IP, hostname, SNMP community) or any constraints, leaving agents to infer meaning solely from the schema type.

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?

Description clearly states the tool reports printer status via PRINTER-MIB (RFC 3805) covering supplies, trays, bins, alerts, and supports multiple brands. It includes handling of sentinel values, making the purpose specific and distinct from sibling tools like system_info or interfaces_list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool over alternatives (e.g., snmp_walk, snmp_get) or prerequisites like SNMP configuration. The description only lists supported printer brands but does not differentiate use cases.

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

snmp_bulk_walkA

Walk an OID subtree via GETBULK (SNMPv2c+). Faster than snmp_walk for large tables; falls back to GETNEXT with a warning on v1 hosts. max_repetitions defaults to 25.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes
root_oidYes
max_repetitionsNo

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden. It discloses the GETBULK mechanism, fallback to GETNEXT with warning on v1, and default max_repetitions. It does not mention side effects, rate limits, or authentication needs, but for a read-only SNMP walk, this is reasonably transparent.

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?

Two sentences, no wasted words. First sentence states purpose and mechanism. Second sentence adds performance comparison, fallback, and default. Highly efficient.

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?

For a 3-param tool with no output schema and no annotations, the description covers purpose, usage conditions, and a key parameter. Missing details on return format, error handling, or credentials, but given the simplicity and typical SNMP context, it is fairly complete.

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?

Schema description coverage is 0%, so the description must add meaning. It explains max_repetitions (default 25) but does not describe host or root_oid. Host and root_oid are self-explanatory to some extent, but the lack of schema description combined with only one param explained results in moderate added value.

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 clearly states the tool walks an OID subtree via GETBULK for SNMPv2c+. It distinguishes from sibling snmp_walk by noting it is faster for large tables and provides a fallback mechanism, making the purpose specific and well-defined.

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?

The description gives guidance on when to use (large tables, faster than snmp_walk) and when fallback occurs (v1 hosts with warning). It implies snmp_walk as an alternative but does not explicitly list when not to use or cover all sibling tools. Clear context but missing exclusions.

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

snmp_getA

Fetch one or more OIDs in a single SNMP GET-Request. Accepts numeric (e.g. 1.3.6.1.2.1.1.5.0) and a small set of symbolic forms (e.g. SNMPv2-MIB::sysName.0). Returns a dict keyed by OID with {value, type} per varbind.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes
oids_inYes

TDQS

A3.5/5.0
Behavior3/5

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

Without annotations, the description carries the full burden. It discloses the return format (dict with value and type) but omits other behavioral traits like error handling, timeout behavior, or limits on OID count. This is adequate but not comprehensive.

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?

Two concise sentences: the first states the action and input formats, the second describes the output. No redundant information, every part earns its place.

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?

For a simple 2-parameter tool with no output schema, the description covers input format and output structure. It lacks details on error cases, OID limits, or default behavior, but is fairly complete for its complexity.

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?

The schema has 0% description coverage, so the description adds significant value. It explains that host is the target and oids_in is a list of OIDs, clarifying acceptable formats (numeric and symbolic). This compensates well for the schema's lack of descriptions, though it could detail the host format.

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?

The description clearly states it fetches one or more OIDs via a single SNMP GET-Request, specifying acceptable formats (numeric and symbolic). This differentiates from sibling tools like snmp_walk but doesn't explicitly contrast with them, keeping it just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use snmp_get versus alternative sibling tools (e.g., snmp_walk, snmp_bulk_walk). The description does not mention prerequisites or contexts where this tool is preferred, leaving the agent to infer usage.

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

snmp_tableA

Walk and tabularize an SNMP table. Returns {table_oid, rows: [{index, : value, ...}, ...]}. Column-name mapping is best-effort: unknown columns are keyed by numeric OID.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes
table_oidYes

TDQS

A4.1/5.0
Behavior4/5

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

Without annotations, the description carries the full burden. It discloses column-name mapping best-effort behavior and fallback to numeric OIDs, which is a key behavioral trait. However, it lacks details on permissions, rate limits, or idempotency.

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?

Two well-structured sentences. The first conveys the core purpose and output format, the second adds a caveat. No redundant information.

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?

Given the tool has no output schema and two simple parameters, the description explains the return structure and a key limitation (column mapping). It covers most needed context for invocation, though error behavior or SNMP version requirements are missing.

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

Parameters2/5

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

With 0% schema description coverage, the description does not explain the 'host' or 'table_oid' parameters beyond their names. No additional meaning or constraints are provided, leaving the agent to infer from context.

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 clearly states the action 'Walk and tabularize an SNMP table' and specifies the output format. It distinguishes from sibling tools like 'snmp_walk' which returns flat data, by focusing on tabular output.

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?

The description implies usage for SNMP table data via 'tabularize an SNMP table', but does not explicitly state when to use this tool vs alternatives (e.g., snmp_get, snmp_walk). No exclusions are given.

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

snmp_walkA

Walk an OID subtree via GETNEXT chain. Terminates on endOfMibView or when the next OID leaves the subtree. Returns a list of {oid, value, type} rows.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes
root_oidYes

TDQS

A4/5.0
Behavior4/5

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

No annotations exist, so description carries full burden. It describes the GETNEXT mechanism, termination criteria (endOfMibView, leaving subtree), and return format (list of objects). It lacks details on side effects or performance but is sufficient for a read-only tool.

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 two sentences long, front-loaded with the action, and contains no redundant information. Every word adds value.

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?

Given low complexity (2 simple params) and no output schema, the description covers the main behavior and return structure. Missing details on errors or prerequisites but still adequate for a straightforward tool.

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?

Schema has 0% coverage, so description must compensate. It adds meaning to root_oid as the start of the subtree and implies host is the target. However, it does not specify format or constraints (e.g., host string type). Baseline 3 given minimal extra context.

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 clearly states 'Walk an OID subtree via GETNEXT chain', specifying the verb and resource. It also mentions termination conditions, which distinguishes it from sibling tools like snmp_get (single OID) and snmp_bulk_walk (different protocol).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for walking a subtree but does not explicitly contrast with siblings like snmp_bulk_walk or snmp_get. No when-not or alternative guidance is provided.

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

system_infoB

Fetch the SNMPv2-MIB::system group (RFC 3418): sysDescr, sysObjectID, sysUpTime (centiseconds and seconds), sysContact, sysName, sysLocation, sysServices.

ParametersJSON Schema
NameRequiredDescriptionDefault
hostYes

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description must disclose behavioral traits. It states the tool fetches information (a read operation) but does not confirm idempotence, safety, or lack of side effects. Given the SNMP context, it is likely a read-only fetch, but this is not explicitly stated. The description lacks clarity on response size or potential errors.

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?

The description is a single, well-structured sentence that front-loads the main action and lists the returned OIDs. It is efficient, though it could be slightly improved by separating the list of OIDs or adding a note about parameter requirements.

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?

For a simple tool with one parameter and no output schema, the description provides a complete list of retrieved OIDs, which is the core information needed. However, it lacks details about error conditions, response format, or whether the tool supports authentication options, which would be helpful for the agent.

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

Parameters2/5

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 add meaning to the 'host' parameter beyond the schema's type declaration. It does not explain formatting, examples, or constraints (e.g., IP vs hostname). The parameter remains ambiguous.

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 explicitly identifies the specific MIB group (SNMPv2-MIB::system) and lists the OIDs retrieved, making it clear what information the tool returns. The name 'system_info' is generic but the description adds precise context, and it is clearly distinct from sibling tools like interfaces_list or snmp_walk.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as snmp_get or snmp_walk. There is no mention of prerequisites, conditions, or exclusions, leaving the agent to infer the use case solely from the name and listed OIDs.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 9 tool updatesv0.0.0
    • First observeddevice_detect
    • First observedhost_resources
    • First observedinterfaces_list
    • First observedprinter_status
    • First observedsnmp_bulk_walk
    • First observedsnmp_get
    • First observedsnmp_table
    • First observedsnmp_walk
    • First observedsystem_info
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation4/5

Tools are largely distinct, but snmp_walk and snmp_bulk_walk share the same purpose (walking an OID subtree) differing only in method, which could cause confusion. Additionally, snmp_table is a specialized walk. However, descriptions clarify the differences.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., device_detect, snmp_get, interfaces_list), making it easy for agents to predict and select the correct tool.

Tool Count5/5

With 9 tools, the server covers core SNMP operations (get, walk, bulk walk, table) and common MIB groups (system, interfaces, host resources, printer). The count is well-balanced for its scope.

Completeness5/5

The tool set provides both low-level SNMP access and high-level summaries for common device types. It includes detection (device_detect), system info, interfaces, resources, and printer status. The only notable gap is lack of SNMP SET, but that aligns with the server's focus on read-only monitoring.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • network-mcp-server

    edutacara
    A
    license
    Not graded
    quality
    D
    maintenance
    MCP server for network operations that lets AI assistants interact with Cisco/Juniper network devices through safe, well-defined tools like compliance audits and configuration backups.
    MIT

  • Device MCP Server

    rajib884
    A
    license
    A
    quality
    B
    maintenance
    A comprehensive MCP server for network device management via SSH/Telnet. Supports multiple vendors such as Cisco IOS and BDCOM, enabling AI assistants to execute commands and manage routers, switches, and firewalls.
    4
    MIT

  • MCP PLC Core

    Maxkrempl
    F
    license
    B
    quality
    B
    maintenance
    Universal MCP server for industrial PLC communication, enabling AI agents to read sensors, alarms, status, setpoints, and write setpoints via adapters for Modbus, S7, or custom PLCs.
    6
    -

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/acato/snmp-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server