Skip to main content
Glama
jshsakura

mfa-servicenow-mcp

by jshsakura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

diff_local_component

Compare local ServiceNow edits against remote components or another download root; get status, diffs, changed-line counts, or fast-forward clean files.

Instructions

Diff local edits vs remote (or compare_to root); verdict=True status-only, refresh=True fast-forwards.

Input Schema

NameRequiredDescriptionDefault
hunkNoShow only this diff hunk (1-based, from hunk_index), uncut.
pathYesLocal file, widget dir, or download root (file→diff, root→summary).
fieldNoLimit the diff to one field (e.g. script, client_script).
refreshNoFast-forward clean local files to the live server body; edits kept.
verdictNoStatus-only: verdict + changed-line counts, no diff bodies; dirs scan all.
compare_toNo2nd download root to diff against instead of remote (dev-vs-test, no network).
context_linesNoNumber of context lines in unified diff output (default 3)
cross_instanceNoDiff a copy from another instance against the same-named record here.
on_local_editsNoWith refresh, edited files: keep, clean (take server), stash (set aside first).keep

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.24.83
    • addedInput schema / properties / cross_instance
      Added value: +{
+  "description": "Diff a copy from another instance against the same-named record here.",
+  "type": "boolean"
+}
    • addedInput schema / properties / field
      Added value: +{
+  "description": "Limit the diff to one field (e.g. script, client_script).",
+  "type": "string"
+}
    • addedInput schema / properties / hunk
      Added value: +{
+  "description": "Show only this diff hunk (1-based, from hunk_index), uncut.",
+  "type": "integer"
+}
    • addedInput schema / properties / on_local_edits
      Added value: +{
+  "default": "keep",
+  "description": "With refresh, edited files: keep, clean (take server), stash (set aside first).",
+  "enum": [
+    "keep",
+    "clean",
+    "stash"
+  ],
+  "type": "string"
+}
  2. Addedv1.21.21
  3. Removedv1.21.13
  4. First observedv1.18.41

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully signals that verdict=True yields no diff bodies and that refresh=True performs a fast-forward (a mutating action on local files), which is real behavioral disclosure. However it omits auth/network implications, reversibility, and how edits are handled on refresh (only implied via the schema's on_local_edits).

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

Conciseness4/5

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

A single dense sentence front-loads the core purpose and mode toggles with no filler. It is aggressively compressed, but every clause maps to a real behavior, so nothing is wasted.

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?

For a 9-parameter tool with mutation semantics and no annotations or output schema, the description is thin: it never describes the diff output format, error behavior, or prerequisites. The rich schema covers parameters, but return-value expectations remain unspecified.

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 coverage is 100%, so the baseline is 3. The description's mentions of verdict and refresh largely restate what those parameter descriptions already say ('Status-only', 'Fast-forward clean local files...'), adding little new semantic meaning.

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 (diff) and scope (local edits vs remote, or a compare_to root), which is clear for an agent. It does not name or differentiate itself from nearby siblings like audit_local_sources or get_developer_changes, so it stops short of a 5.

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?

It hints at mode selection ('verdict=True status-only, refresh=True fast-forwards') and an alternative diff target (compare_to root), which is implied usage. It never states when to prefer this over sibling inspection tools or when to avoid it.

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