ServiceNow MCP Server

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'List service catalog items' implies a read-only operation but doesn't specify whether this requires authentication, what format the results come in, whether there are rate limits, or if the listing includes all items or only accessible ones. For a tool with zero annotation coverage, this minimal description leaves critical behavioral aspects undocumented.

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?

The description is maximally concise at just four words: 'List service catalog items.' It's front-loaded with the core action and resource, with no unnecessary words or redundant information. While it may be too brief for completeness, as a standalone statement it's efficiently structured.

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?

Given the complexity (5 sub-parameters in a nested structure), no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain what 'service catalog items' are in this context, how results are returned, what filtering options exist, or any behavioral characteristics. For a tool with this level of complexity and no supporting structured data, the description should provide much more context.

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?

The description provides zero information about parameters, while the schema description coverage is 0% (the schema has descriptions, but coverage calculation shows 0%). With 1 parameter (a nested object containing 5 sub-parameters) and no parameter information in the description, there's a significant gap. The description doesn't compensate for the schema's lack of coverage, leaving agents with insufficient understanding of how to use the tool effectively.

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 description 'List service catalog items' clearly states the verb ('List') and resource ('service catalog items'), providing a basic understanding of the tool's function. However, it doesn't distinguish this tool from its sibling 'list_catalog_categories' or 'get_catalog_item', leaving ambiguity about scope and specificity. The purpose is clear but lacks differentiation from related tools.

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?

The description provides no guidance on when to use this tool versus alternatives like 'get_catalog_item' (for single items) or 'list_catalog_categories' (for categories). There's no mention of prerequisites, typical use cases, or contextual factors that would help an agent choose this tool appropriately among the many sibling tools available.

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