Skip to main content
Glama
jshsakura

mfa-servicenow-mcp

by jshsakura

download_app_sources

Download all source code for a ServiceNow app scope (including dependencies) to local disk for backup, audit, or editing. Requires scope; first step in workflow, not portal.

Instructions

FULL/all source of an app scope to disk (all groups+deps). scope REQUIRED — ask user. Step 1, not portal.

Input Schema

NameRequiredDescriptionDefault
scopeYesREQUIRED app namespace (x_...) or app name. Ask the user if not given.
resumeNoSkip stages a prior timed-out call finished. false = download everything again.
page_sizeNo
backgroundNoRun in background; call again (same args) to poll progress, then result.
output_dirNoOmit — default path is canonical and reused. Set only for one-off export.
build_graphNoAlso run the offline audit (relationship graphs) after download. No API cost.
incrementalNoRe-download only records changed since last sync (per-record sys_mod_count).
only_activeNo
include_schemaNo
on_local_editsNoFiles with your edits: keep, clean (take server), stash (set aside, take server).keep
acl_script_onlyNo
auto_resolve_depsNoAfter download, fetch missing cross-scope SI/widget/provider/ui_macro deps.
reconcile_deletionsNoWarn about local records deleted on the instance. No auto-delete.
max_records_per_typeNo
include_widget_sourcesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.24.83
    • changedInput schema / properties / incremental / description
      Previous value: -"Re-download only records changed since last sync (sys_updated_on)."New value: +"Re-download only records changed since last sync (per-record sys_mod_count)."
    • 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. Changed1 schema field changedv1.24.61
    • changedInput schema / properties / resume / description
      Previous value: -"Replay finished stages from a prior timed-out call; skip re-downloading them."New value: +"Skip stages a prior timed-out call finished. false = download everything again."
  3. First observedv1.18.41

TDQS

A3.7/5.0
Behavior3/5

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

No annotations exist, so the description carries the disclosure burden, and it only adds that everything (all groups + deps) is pulled and that it is step 1 of a workflow. It does not state the operation is a read/non-destructive sync, confirm auth requirements, or describe disk-side effects, though the schema's option descriptions partially compensate.

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?

Extremely tight and front-loads the core action followed by the required-argument and routing cues. The telegraphic fragment style ('Step 1, not portal') is efficient but slightly cryptic, costing it a point.

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?

For a 15-parameter mutation-to-disk tool with no annotations and no output schema, a single sentence fragment is thin. The 'Step 1' cue implies a larger workflow but never describes the steps, expected artifacts, or how the heavy option set interacts, leaving the agent to piece context together from schema fields alone.

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 60%, so most parameters are self-documented. The description only reinforces the scope parameter ('REQUIRED — ask user'), adding no meaning for the other 14 options such as resume, incremental, or on_local_edits. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb (download) and resource (all source of an app scope) plus scope of the pull ('all groups+deps'). It explicitly routes away from the sibling by declaring 'not portal', letting an agent distinguish it from download_portal_sources without opening either schema.

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?

Provides a clear usage signal with 'Step 1' and the exclusion 'not portal', and reinforces the required argument ('scope REQUIRED — ask user'). It stops short of naming the sibling explicitly or stating when a full download is inappropriate versus the incremental/background paths.

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