Skip to main content
Glama
J-MaFf

s2-netbox-mcp

by J-MaFf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

get_card_access_details

Read-only

Retrieve access details for a card by encoded number and card format to see where and when its credential was used, with optional reader and cardholder names.

Instructions

Returns card/credential access details for a given card (wraps NBAPI GetCardAccessDetails). Identifies the card by ENCODEDNUM + CARDFORMAT, not PERSONID — GetCardAccessDetails has no PERSONID parameter. RESOLVEDESCRIPTIONS defaults to true — an inverted, opt-out default (unlike most optional booleans in this codebase): each returned ACCESS record is enriched with the reader's human-readable READERDESCRIPTION via one GetReaders full-table fetch per call (not per record); set RESOLVEDESCRIPTIONS: false to skip it. Set RESOLVENAMES: true to enrich the response with the card owner's FIRSTNAME/LASTNAME/FULLNAME/NOTES (default false — off) via a single GetPerson lookup for the card's one PERSONID — cheaper than get_access_history's RESOLVENAMES, which pays one GetPerson call per distinct person across many records, since a card has exactly one owner. The four fields land on the top level of the response, alongside PERSONID/DISABLED/EXPDATE, not on each ACCESS record.

Input Schema

NameRequiredDescriptionDefault
CARDFORMATYesRequired. The card format of ENCODEDNUM.
ENCODEDNUMYesRequired. The encoded card number whose access details should be retrieved.
MAXRECORDSNoOptional. Maximum number of access records to return.
OLDESTDTTMNoOptional. Oldest date/time to include in the returned access records.
RESOLVENAMESNoOptional (default false). Enrich the top level of the response with the card owner's FIRSTNAME/LASTNAME/FULLNAME/NOTES via a single GetPerson lookup for the response's top-level PERSONID (one lookup per call, not one per ACCESS record — a card has exactly one owner).
RESOLVEDESCRIPTIONSNoOptional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Enrich each returned ACCESS record with the reader's human-readable READERDESCRIPTION via one GetReaders full-table fetch per call (not per record). Set to false to skip it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.3.0
    • addedInput schema / properties / RESOLVEDESCRIPTIONS
      Added value: +{
+  "description": "Optional (default true — on by default; the inverse of this codebase's usual optional-boolean default). Enrich each returned ACCESS record with the reader's human-readable READERDESCRIPTION via one GetReaders full-table fetch per call (not per record). Set to false to skip it.",
+  "type": "boolean"
+}
    • addedInput schema / properties / RESOLVENAMES
      Added value: +{
+  "description": "Optional (default false). Enrich the top level of the response with the card owner's FIRSTNAME/LASTNAME/FULLNAME/NOTES via a single GetPerson lookup for the response's top-level PERSONID (one lookup per call, not one per ACCESS record — a card has exactly one owner).",
+  "type": "boolean"
+}
  2. First observedv0.2.3

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true, so the description carries real weight and delivers: the inverted, opt-out RESOLVEDESCRIPTIONS default, the exact cost model (one GetReaders full-table fetch per call, not per record), the off-by-default RESOLVENAMES behavior, and where the enriched fields land in the response. This is behavioral detail an agent cannot get from the annotations or schema.

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 and lookup-key constraint are front-loaded, and most sentences carry non-obvious information. It is a dense single block, though, and the RESOLVENAMES/RESOLVEDESCRIPTIONS passages substantially duplicate the schema descriptions, which slightly dilutes signal per word.

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 work of explaining return shape ('the four fields land on the top level... alongside PERSONID/DISABLED/EXPDATE') plus the enrichment and cost behavior—enough to call it correctly. It does not cover pagination semantics of MAXRECORDS or empty/error results, so it is not fully exhaustive.

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 description coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema by explaining why RESOLVEDESCRIPTIONS is on by default and what each enrichment costs. The RESOLVENAMES/RESOLVEDESCRIPTIONS sentences largely restate schema text, but the performance rationale and output-placement notes are additive.

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 ('Returns card/credential access details for a given card') and immediately scopes the lookup key ('Identifies the card by ENCODEDNUM + CARDFORMAT, not PERSONID'), which distinguishes it from person-centric siblings. It also names the underlying primitive (GetCardAccessDetails) and its limitation, so an agent can route correctly 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 context for the RESOLVENAMES choice by contrasting it with get_access_history's costlier per-person lookup, which helps an agent pick the cheaper tool. However it never states an explicit when-to-use/when-not for the tool as a whole versus siblings like get_access_history or get_reader_access_history; the selection guidance is implied rather than spelled out.

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