Skip to main content
Glama
J-MaFf

s2-netbox-mcp

by J-MaFf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_access_level

Read-only

Retrieve a single access level's details by ACCESSLEVELKEY from an S2 NetBox system, optionally resolving time spec and reader group names.

Instructions

Returns the details of a single access level for a given ACCESSLEVELKEY (wraps NBAPI GetAccessLevel). RESOLVEGROUPNAMES defaults to true — an inverted, opt-out default (unlike most optional booleans in this codebase): the raw response carries only bare TIMESPECGROUPKEY/READERGROUPKEY/THREATLEVELGROUPKEY foreign keys, so this resolves TIMESPECGROUPKEY and READERGROUPKEY into new sibling TIMESPECGROUPNAME/READERGROUPNAME fields via one full-table GetTimeSpecGroups fetch and one full-table GetReaderGroups fetch per call — a fixed cost regardless of anything else, since a single access level carries exactly one of each key. THREATLEVELGROUPKEY is never resolved (no NBAPI read command exists for threat level groups). Set RESOLVEGROUPNAMES: false to skip both fetches and return the response exactly as GetAccessLevel provides it.

Input Schema

NameRequiredDescriptionDefault
ACCESSLEVELKEYYesRequired. The unique ACCESSLEVELKEY of the access level to retrieve.
RESOLVEGROUPNAMESNoOptional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Resolves TIMESPECGROUPKEY/READERGROUPKEY into new TIMESPECGROUPNAME/READERGROUPNAME sibling fields via one full-table GetTimeSpecGroups fetch and one full-table GetReaderGroups fetch per call (each made only when that axis's key is non-empty; an empty/absent key on one axis yields '' for that axis's name without affecting the other). THREATLEVELGROUPKEY is never resolved — no NBAPI read command exists for threat level groups. Set to false to skip both fetches and return the response exactly as GetAccessLevel provides it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / RESOLVEGROUPNAMES
      Added value: +{
+  "description": "Optional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Resolves TIMESPECGROUPKEY/READERGROUPKEY into new TIMESPECGROUPNAME/READERGROUPNAME sibling fields via one full-table GetTimeSpecGroups fetch and one full-table GetReaderGroups fetch per call (each made only when that axis's key is non-empty; an empty/absent key on one axis yields '' for that axis's name without affecting the other). THREATLEVELGROUPKEY is never resolved — no NBAPI read command exists for threat level groups. Set to false to skip both fetches and return the response exactly as GetAccessLevel provides it.",
+  "type": "boolean"
+}
  2. First observedv0.2.3

TDQS

A4/5.0
Behavior5/5

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

Annotations supply only readOnlyHint=true; the description goes well beyond by disclosing the inverted opt-out default, the exact per-call cost (one full-table GetTimeSpecGroups and one GetReaderGroups fetch), the empty-key edge case, and the fact that THREATLEVELGROUPKEY is never resolved. This is exactly the kind of hidden behavior an agent cannot get from structured fields.

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

Conciseness3/5

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

Purpose is front-loaded in the opening clause, which is good, but the remainder is a single dense mega-sentence that re-explains RESOLVEGROUPNAMES almost verbatim from the schema. The cost/behavior detail earns its place, but the duplication and lack of sentence breaks hurt readability.

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?

With no output schema, the description does the heavy lifting on return shape by naming the new TIMESPECGROUPNAME/READERGROUPNAME sibling fields and stating the raw response otherwise passes through. It omits error behavior for an invalid or missing ACCESSLEVELKEY, which keeps it short of a 5.

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 100% and the schema's RESOLVEGROUPNAMES description already carries the inverted-default note and the resolution mechanics, so the description's parameter content is largely a restatement. It adds no syntax or format detail beyond what the schema already documents, making 3 the correct baseline.

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?

States a precise verb+resource: 'Returns the details of a single access level for a given ACCESSLEVELKEY'. The singular 'single' plus the explicit key parameter cleanly separates it from the sibling get_access_levels (plural) and get_access_level_names without the agent needing to open any schema.

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?

It gives clear guidance on the parameter choice (when to set RESOLVEGROUPNAMES: false to skip fetches), but never states when to call this tool versus the many adjacent siblings (get_access_levels, get_access_level_names, get_access_level_group). The single-vs-list distinction is implied by the name only, so usage is inferred rather than stated.

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

Deploy Server

Other Tools