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

The crucial non-obvious behavior is disclosed: credentials are entered by the user inside Local MCP and never transit the AI, so the agent knows it cannot programmatically authenticate. However, the annotations declare destructiveHint=true and readOnlyHint=false, and the description never reconciles that with what is otherwise an informational/instructional tool, leaving an agent unsure whether calling it mutates something.

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?

It is short and front-loads the security constraint, but the first sentence is pure repetition of the title and the nested UI path with its parenthetical fallback is dense and hard to parse. Roughly a third of the text is navigation detail rather than decision-relevant information for the agent.

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?

With an output schema present, return values need no explanation, and the description covers the security model and both use cases for a zero-required-parameter tool. The remaining gap is the unresolved signposted danger from destructiveHint and the lack of any note about what becomes available after connecting.

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 is a single optional parameter whose schema description already says it is 'Ignored; kept for older clients,' giving 100% coverage. The prose adds nothing about parameters, but the schema baseline of 3 applies since no clarification is needed.

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?

The opening sentence merely restates the name, but the closing sentence makes the actual function explicit: 'Call this to get these steps, or to check whether ServiceNow is already connected.' That distinguishes it from the operational servicenow_* siblings and from disconnect_servicenow, letting an agent recognize it as an onboarding/status tool rather than an API action.

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?

Two clear invocation triggers are given (retrieve the setup steps, or verify current connection state), which is enough context to select the tool. There is no explicit when-not guidance or routing to servicenow_list_my_incidents etc. once connected, which keeps it short of a 5.

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