Skip to main content
Glama
J-MaFf

s2-netbox-mcp

by J-MaFf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_time_spec_groups

Read-only

Lists time spec groups configured in S2 NetBox and resolves member keys to names for readable schedules. Set RESOLVEMEMBERNAMES:false to return raw keys.

Instructions

Lists time spec groups configured on the NetBox system (wraps NBAPI GetTimeSpecGroups). RESOLVEMEMBERNAMES defaults to true — an inverted, opt-out default (unlike most optional booleans in this codebase): GetTimeSpecGroups' TIMESPECKEYS.TIMESPECKEY member field carries only bare TIMESPECKEY strings, so this replaces each group member with a {TIMESPECKEY, NAME} object via one GetTimeSpecs full-table fetch per call (not per group/member). An unmatched (unknown/deleted) member key resolves to NAME: ''. Applies only to this plural tool, not the singular get_time_spec_group (confirmed broken/NOT FOUND on this controller — out of scope). Set RESOLVEMEMBERNAMES: false to skip the fetch and return TIMESPECKEYS exactly as GetTimeSpecGroups provides it (bare string or array of strings).

Input Schema

NameRequiredDescriptionDefault
STARTFROMKEYNoOptional. Pagination cursor to continue listing from a previous call.
RESOLVEMEMBERNAMESNoOptional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Replaces each group's TIMESPECKEYS.TIMESPECKEY bare member key(s) with {TIMESPECKEY, NAME} objects via one GetTimeSpecs full-table fetch per call (not per group/member); an unmatched key resolves to NAME: ''. Set to false to skip the fetch and return TIMESPECKEYS exactly as GetTimeSpecGroups provides it (bare string or array of strings).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / RESOLVEMEMBERNAMES
      Added value: +{
+  "description": "Optional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Replaces each group's TIMESPECKEYS.TIMESPECKEY bare member key(s) with {TIMESPECKEY, NAME} objects via one GetTimeSpecs full-table fetch per call (not per group/member); an unmatched key resolves to NAME: ''. Set to false to skip the fetch and return TIMESPECKEYS exactly as GetTimeSpecGroups provides it (bare string or array of strings).",
+  "type": "boolean"
+}
  2. First observedv0.2.3

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, so the description carries real weight and delivers: the inverted opt-out default, the one full-table GetTimeSpecs fetch per call (not per group), the unmatched-key-to-empty-string behavior, and the exact return shape with the flag off. These are non-obvious costs and edge cases an agent could not infer elsewhere.

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?

Purpose is front-loaded and the sentences are dense with substance rather than filler. There is mild duplication since the RESOLVEMEMBERNAMES explanation is restated in the schema, and the parentheticals stack up, but nothing is wasted.

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

Completeness5/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 fills the gap by describing the returned TIMESPECKEYS shape in both modes, plus the pagination cursor semantics via STARTFROMKEY. Nothing needed to invoke or interpret this tool is missing.

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 RESOLVEMEMBERNAMES schema text is essentially identical to the description text, so the description adds no parameter meaning beyond the schema. The only extra is the scope note that the behavior applies to this plural tool only. Baseline 3 applies.

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 specific verb and resource ('Lists time spec groups configured on the NetBox system') and even names the underlying API call. It explicitly distinguishes itself from the singular sibling get_time_spec_group and from get_time_specs, so an agent can separate it from neighbors without opening the schema.

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 clear operational guidance: set RESOLVEMEMBERNAMES to false to skip the fetch, and the note that the singular get_time_spec_group is broken and out of scope steers the agent away from a dead end. It stops short of an explicit when-to-use-this-vs-get_time_specs rule, but the context is unambiguous.

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