Skip to main content
Glama
tedorigawa001

ServiceNow-MCP

by tedorigawa001
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

review_update_set_best_practices

Read-onlyIdempotent

Review ServiceNow Update Set payloads to verify adherence to development best practices. Analyze complex script logic and UI constraints within Update Sets to identify potential deployment issues and ensure code quality.

Instructions

Read-only PoC review of Update Set payloads by sys_id, Australia only. Defaults: AU-BR-001/002 and AU-CL-004. Explicit BR opt-ins: AU-QRY-001 (literal addQuery LIKE, not encoded queries), AU-BR-004 (script variable declarations), AU-BR-005 (before BR post-abort processing), AU-BR-007 (stored before_display current writes). Explicit Client Script opt-in AU-CL-006: bounded g_form setMandatory/setVisible/setDisplay/setReadOnly calls as UI Policy considerations. Complex logic and UI constraints are not blanket violations or automatic exemptions; suitability/order/UI compatibility need review. Never auto-migrate or add return/update. Source-free low-confidence candidates with official sources, not certification. Unresolved evidence prevents analysis_complete. selection_mode=review_targets returns 0.3; omitted/bounded_all keeps 0.2. ACL-before-limit/coarse prefixes can hide targets. Zero findings never establish safety. Limits: 100 metadata rows plus lookahead, 60 seconds. No code execution/external LLM lookup.

Input Schema

NameRequiredDescriptionDefault
instanceNo
max_recordsNo
selection_modeNo
update_set_sys_idYes
requested_rule_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.0
    • changedInput schema / properties / requested_rule_ids / items / enum
      Previous value: -[
-  "AU-BR-001",
-  "AU-BR-002",
-  "AU-CL-004"
-]New value: +[
+  "AU-BR-001",
+  "AU-BR-002",
+  "AU-CL-004",
+  "AU-QRY-001",
+  "AU-BR-004",
+  "AU-BR-005",
+  "AU-BR-007",
+  "AU-CL-006"
+]
    • changedInput schema / properties / requested_rule_ids / maxItems
      Previous value: -3New value: +8
  2. Addedv1.15.1

TDQS

A3.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses hard limits (100 metadata rows plus lookahead, 60 seconds), safety guarantees (no code execution, no external LLM lookup, never auto-migrate), confidence semantics (source-free low-confidence, not a certification), and that zero findings never establish safety. This is unusually rich behavioral context.

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

Conciseness3/5

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

The purpose is front-loaded correctly, but the remainder is a dense, telegraphic block mixing defaults, rule names, caveats and limits with no sentence structure or grouping. Much of it earns its place, but readability suffers and key clauses blur together.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, rule-driven review tool with no output schema, the description supplies limits, safety guarantees and confidence caveats so an agent can call it and interpret results. The unexplained selection_mode scores and uncovered 'instance' parameter are the main remaining gaps.

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 0%, so the description must carry parameter meaning. It covers requested_rule_ids and selection_mode fairly well, but the '0.3' vs '0.2' values are never explained, the 'instance' parameter is only implied by 'Australia only', and max_records is only indirectly referenced via the row limit.

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 (read-only review), resource (Update Set payloads) and scope (by sys_id, Australia only). The nature of the tool is clear, but acronyms like 'PoC' and the 'AU-BR/AU-CL' rule codes are unexplained, and the description never names the sibling tools it differs from (e.g. preview_update_set, scan_update_set_sca).

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?

Provides default rules (AU-BR-001/002, AU-CL-004) and instructs on opt-ins via requested_rule_ids, plus selection_mode tradeoffs, so intended usage is inferable. However there is no explicit statement of when NOT to use it versus the update-set siblings (preview, scan, export), leaving routing ambiguous.

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