Verify server authentication to the S2 NetBox controller and return the NBAPI version string. Use it to confirm connectivity before running access-control queries.
Confirms the server can authenticate to the configured S2 NetBox controller and returns the NBAPI version string (wraps GetAPIVersion). No parameters required.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.2.3Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring this a safe read, the description adds genuine behavioral context: it performs an authentication handshake against the configured controller and returns the API version string (wrapping GetAPIVersion). It does not describe failure behavior (error vs. false) or timeout/retry traits, which would be valuable for a connection check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence delivers the purpose, the return value, the underlying implementation, and the parameter situation with zero filler. Nothing could be removed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter, read-only diagnostic, the description covers what it does and what it returns, and there is no output schema requiring further explanation. The only real gap is failure/error behavior, which matters somewhat for a connectivity check but does not block correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The explicit note that no parameters are required is accurate and consistent with the empty schema, adding nothing that contradicts it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it confirms server-to-controller authentication and returns the NBAPI version string, naming the underlying GetAPIVersion call. It is unambiguous, but it does not differentiate itself from the sibling diagnostic tools (e.g. ping_app), so an agent must still infer which connectivity check to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than stated: the description says it confirms authentication, so an agent can infer it is a connectivity/credential check. There is no explicit when-to-use/when-not guidance and no mention of the alternative ping_app sibling, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.