Skip to main content
Glama
Sign In
mfa-servicenow-mcp

mfa-servicenow-mcp

by jshsakura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

download_portal_sources

Exports ServiceNow portal widget sources for targeted widgets or an entire scope, including client/server scripts, templates, and CSS.

Instructions

Targeted portal widgets/providers. Whole app: download_app_sources. widget_ids=one widget.

Input Schema

NameRequiredDescriptionDefault
scopeNoScope namespace (x_app) or app name; auto-resolved to the namespace.
page_sizeNo
output_dirNoOmit — default path is canonical and reused. Set only for one-off export.
widget_idsNoOptional list of widget sys_id/id/name. If empty, exports all widgets in scope.
incrementalNoRe-download only records changed since last sync. Full-scope only.
max_widgetsNo
on_local_editsNoFiles with your edits: keep, clean (take server), stash (set aside, take server).keep
include_widget_cssNo
reconcile_deletionsNoWarn about local records deleted on the instance. No auto-delete.
include_widget_templateNo
include_widget_link_scriptNo
include_widget_client_scriptNo
include_widget_server_scriptNo
include_linked_script_includesNo
include_linked_angular_providersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.24.83
    • addedInput schema / properties / on_local_edits
      Added value: +{
+  "default": "keep",
+  "description": "Files with your edits: keep, clean (take server), stash (set aside, take server).",
+  "enum": [
+    "keep",
+    "clean",
+    "stash"
+  ],
+  "type": "string"
+}
  2. Addedv1.21.21
  3. Removedv1.21.20
  4. First observedv1.18.41

TDQS

B3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden, and it discloses essentially nothing. For a tool that writes records into a local tree (overwriting files, honoring on_local_edits semantics, possibly reconciling deletions), there is no statement about what gets touched on disk, auth needs, or side effects — the safety-relevant behavior only appears buried in schema param descriptions.

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?

Three telegraphic fragments are front-loaded and free of filler, which is good, but the extreme brevity is underspecification rather than discipline. For a 15-parameter tool the description is too thin to be considered well-structured.

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

Completeness2/5

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

Given 15 params, 40% schema coverage, no annotations, and no output schema, the description does not supply enough for confident invocation. It resolves the sibling ambiguity but leaves the download/overwrite semantics and most parameters to inference.

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?

Schema coverage is only 40% across 15 parameters, so the description must compensate, and it adds meaning for just one param ('widget_ids=one widget'). Scope/page_size/output_dir/incremental/max_widgets/reconcile_deletions and the include_* toggles get no narrative treatment, leaving most of a large param surface unexplained.

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?

Names the resource (portal widgets/providers) and draws an explicit boundary against the sibling tool ('Whole app: download_app_sources'), so an agent can distinguish the two. However, no verb is actually stated — the download action is only implied by the tool name, so it falls short of a full verb+resource+scope statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Routes the agent usefully: this tool is for targeted widgets, download_app_sources is for a whole app, and 'widget_ids=one widget' signals the narrowest case. It gives clear context but no explicit when-not conditions (e.g., linking to the declarative-provider workflow or prerequisites).

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