Skip to main content
Glama
junioroliveira1662

ServiceNow Incidents MCP

add_incident_comment

Adds a comment or work note to a ServiceNow incident, requiring the incident ID, text, and comment type.

Instructions

Adiciona comentário (comments) ou nota interna (work_notes), com seleção obrigatória.

A visibilidade segue a configuração da instância. Repetir pode duplicar a entrada.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYes
fieldYes
identifierYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond annotations (non-idempotent, write), the description adds two behavioral warnings: 'visibilidade segue a configuração da instância' and 'repetir pode duplicar a entrada'. These explain the consequences of non-idempotency and the variable scope of visibility, giving the agent extra context for safe invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, the first front-loads the action and the mandatory selection, the second adds relevant behavioral caveats. There is no fluff or duplicated information from the schema.

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?

The description covers the main purpose and risk, but does not explicitly connect the tool to its sibling context (e.g., 'use the identifier returned by list_incidents'). Since an output schema exists, return values are not mandatory to explain, yet the missing parameter linkage makes agent execution harder than it should be.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description does distinguish the two values for 'field', but says nothing explicit about 'identifier' (likely incident ID) or 'text' (the comment content). The agent must infer these from the tool name, which is incomplete and potentially ambiguous.

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?

The description specifies a concrete verb (Adiciona), the target (comentário or nota interna), and differentiates the two fields. The tool name and sibling context make it clear this is a write operation on an incident, not one of the incident lifecycle operations.

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?

The description makes it clear the caller must select between 'comments' and 'work_notes', and implicitly that this is for adding to an existing incident. However, it does not explicitly contrast with sibling tools like update_incident or create_incident, nor does it state when to prefer this over them.

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