Skip to main content
Glama
J-MaFf

s2-netbox-mcp

by J-MaFf
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

search_person_data

Read-only

Search S2 NetBox person records by name, card, access level, UDF, or status filters; omit filters to list all records.

Instructions

Searches for person records matching the given criteria (wraps NBAPI SearchPersonData). Every documented SearchPersonData filter field is modeled explicitly; omit all filters to return every record.

Input Schema

NameRequiredDescriptionDefault
UDF1NoOptional. Search filter on user-defined field UDF1.
UDF2NoOptional. Search filter on user-defined field UDF2.
UDF3NoOptional. Search filter on user-defined field UDF3.
UDF4NoOptional. Search filter on user-defined field UDF4.
UDF5NoOptional. Search filter on user-defined field UDF5.
UDF6NoOptional. Search filter on user-defined field UDF6.
UDF7NoOptional. Search filter on user-defined field UDF7.
UDF8NoOptional. Search filter on user-defined field UDF8.
UDF9NoOptional. Search filter on user-defined field UDF9.
NOTESNoOptional. Match on the person record's notes text.
UDF10NoOptional. Search filter on user-defined field UDF10.
UDF11NoOptional. Search filter on user-defined field UDF11.
UDF12NoOptional. Search filter on user-defined field UDF12.
UDF13NoOptional. Search filter on user-defined field UDF13.
UDF14NoOptional. Search filter on user-defined field UDF14.
UDF15NoOptional. Search filter on user-defined field UDF15.
UDF16NoOptional. Search filter on user-defined field UDF16.
UDF17NoOptional. Search filter on user-defined field UDF17.
UDF18NoOptional. Search filter on user-defined field UDF18.
UDF19NoOptional. Search filter on user-defined field UDF19.
UDF20NoOptional. Search filter on user-defined field UDF20.
DELETEDNoOptional. Include/exclude deleted person records.
HOTSTAMPNoOptional. Match on a card hot-stamp number.
LASTNAMENoOptional. Match on the person's last name.
PERSONIDNoOptional. Match on a specific PERSONID.
FIRSTNAMENoOptional. Match on the person's first name.
CARDFORMATNoOptional. Match persons holding a card in this card format.
CARDSTATUSNoOptional. Match persons holding a card with this card status name.
MIDDLENAMENoOptional. Match on the person's middle name.
MSUENABLEDNoOptional. Match on whether MSU mobile credentials are enabled ("TRUE"/"FALSE").
ACCESSLEVELNoOptional. Match persons assigned this access level.
MOBILEPHONENoOptional. Match on the person's mobile phone number.
CONTACTEMAILNoOptional. Match on the person's office email address.
ALLPARTITIONSNoOptional. Search across all partitions.
NEWESTLASTMODNoOptional. Only include records last modified on/before this date/time.
OLDESTLASTMODNoOptional. Only include records last modified on/after this date/time.
RAWCARDNUMBERNoOptional. Match on a raw (unformatted) card number.
VEHICLELICNUMNoOptional. Match on a vehicle license plate number.
VEHICLETAGNUMNoOptional. Match on a vehicle tag number.
WILDCARDSEARCHNoOptional. Treat text filters as wildcard patterns.
CASEINSENSITIVENoOptional. Perform a case-insensitive match.
WANTCREDENTIALIDNoOptional. Include CREDENTIALID values on returned access cards.
ACCESSLEVELDETAILSNoOptional. Include full access level details in the response.
BLUEDIAMONDENABLEDNoOptional. Match on whether BlueDiamond mobile credentials are enabled ("TRUE"/"FALSE").

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.3.0
    • addedInput schema / properties / BLUEDIAMONDENABLED
      Added value: +{
+  "description": "Optional. Match on whether BlueDiamond mobile credentials are enabled (\"TRUE\"/\"FALSE\").",
+  "type": "string"
+}
    • addedInput schema / properties / CARDFORMAT
      Added value: +{
+  "description": "Optional. Match persons holding a card in this card format.",
+  "type": "string"
+}
    • addedInput schema / properties / CARDSTATUS
      Added value: +{
+  "description": "Optional. Match persons holding a card with this card status name.",
+  "type": "string"
+}
    • addedInput schema / properties / CONTACTEMAIL
      Added value: +{
+  "description": "Optional. Match on the person's office email address.",
+  "type": "string"
+}
    • addedInput schema / properties / MOBILEPHONE
      Added value: +{
+  "description": "Optional. Match on the person's mobile phone number.",
+  "type": "string"
+}
    • addedInput schema / properties / MSUENABLED
      Added value: +{
+  "description": "Optional. Match on whether MSU mobile credentials are enabled (\"TRUE\"/\"FALSE\").",
+  "type": "string"
+}
    • addedInput schema / properties / NOTES
      Added value: +{
+  "description": "Optional. Match on the person record's notes text.",
+  "type": "string"
+}
    • addedInput schema / properties / VEHICLELICNUM
      Added value: +{
+  "description": "Optional. Match on a vehicle license plate number.",
+  "type": "string"
+}
    • addedInput schema / properties / VEHICLETAGNUM
      Added value: +{
+  "description": "Optional. Match on a vehicle tag number.",
+  "type": "string"
+}
  2. First observedv0.2.3

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that it wraps NBAPI SearchPersonData and the omit-all-filters behavior, but says nothing about result volume, pagination, or how multiple filters combine (AND vs OR).

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?

Two sentences, front-loaded with the core purpose and no filler. The parenthetical wrapper name is minor but not wasteful, and the empty-filter behavior is stated compactly.

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?

For a 44-parameter search tool with no output schema, the description is thin: it does not explain filter combination semantics, matching behavior (wildcard/case sensitivity toggles exist), or result shape, all of which an agent must call this correctly would benefit from.

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%, so the schema already documents all 44 filter fields. The description's claim that 'every documented SearchPersonData filter field is modeled explicitly' adds structural reassurance but no per-parameter meaning beyond the schema, matching the baseline 3.

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?

States a specific verb and resource ('Searches for person records matching the given criteria'), which is clear and actionable. However, it never distinguishes itself from the sibling get_person, which fetches a specific person record, leaving the boundary between the two to inference.

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?

'omit all filters to return every record' gives implied usage for the empty case, but there is no explicit when-to-use vs get_person for single-record retrieval, and no exclusions or prerequisites.

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