AI Connectivity for ServiceNow
Docker + PostgreSQL
Connect an MCP client to a defined business dataset, configure the access boundary, and validate the resulting workflow.
What you will leave with
A tested, limited workflow with a clear identity boundary and an agreed process for reviewing agent access.
In this guide
Deployment model
Use this guide to configure the container, data access, and operational controls for a ServiceNow MCP workflow. Choose the data path before configuring storage.
- For live-source access, queries use the connected ServiceNow account. Document its identity and effective access; do not assume that connecting an administrator automatically gives every client a separate permission boundary.
- For retained-data access, the selected database supplies the historical dataset. Configure and review that access separately from the source application's permissions.
- Record the MCP client, transport, endpoint or local process, authentication method, and allowed tools from your deployment configuration. Keep read and write authorization separate.
Use the installation package and version-specific configuration supplied for your deployment. This guide covers the source, host, database, and workflow decisions that remain consistent across package versions.
Before you begin
Bring the application owner, infrastructure owner, and data owner into the same deployment review. Agree the boundaries before configuring a connection.
Decisions to make together
- Which question or task should the agent be able to handle?
- Will it access current source records, retained data, or both?
- Which identity authorizes access, and which operations must remain unavailable?
- A ServiceNow administrator and an approved non-production instance.
- An inventory of tables, reference fields, inherited fields, and attachment requirements.
- An agreed integration identity and a review of the instance access rules.
- The connection authentication method and a list of permitted operations for this workflow.
Prepare ServiceNow
Define the ServiceNow instance, tables, and access rules for the workflow. Use a non-production instance to validate the configuration before applying it to production.
Table and field scope
List required tables and fields, including inherited fields and reference values. Include a record with related tasks or attachments when validating whether the scope is complete.
Access and business rules
Review table and field access with the instance administrator. For any proposed write operation, identify business rules and flows that may run, and agree how the test will be isolated.
Inspect a small ServiceNow record set
Use the REST API Explorer or an approved authenticated REST client against your non-production instance. This example requests ten incidents and their stored reference values. Adjust the table and fields to your approved scope.
HTTP
GET /api/now/table/incident?sysparm_query=ORDERBYsys_id&sysparm_fields=sys_id,number,short_description,caller_id,sys_updated_on&sysparm_limit=10&sysparm_display_value=falseWhat to verify
Check the result array against records visible to the integration identity. Preserve sys_id values for matching; display labels are not stable record keys. An empty result can reflect the query or permissions. For a larger extract, define pagination and reconcile changes during capture. Download required attachment bytes through the Attachment API; a metadata row alone does not preserve the file.
ServiceNow: Table API parameters and responsesPrepare Docker
Prepare a container deployment with explicit network boundaries, persistent storage, and a controlled image version.
Image and configuration
Use the image reference and configuration supplied with your deployment package. Pin the agreed version and keep credentials in your approved secret mechanism rather than the image or source control.
Container networking
Map the routes to the source system and database. A database hostname reachable from the host is not necessarily reachable from a container; validate the route from the deployment network.
State and lifecycle
Identify every persistent volume and its owner. Plan resource limits, logs, restart behavior, and upgrades. Replacing a container must not silently discard the retained data or operating history.
Check the supplied Compose deployment
From the directory containing your approved Compose file, inspect the declared service names and running containers. Replace SERVICE_NAME with an actual name from the first command. These commands do not create or remove containers or volumes.
Shell
docker compose config --services
docker compose ps --all
docker compose logs --tail=50 SERVICE_NAMEWhat to verify
Check for restart loops or connection errors. Confirm that database files, attachments, and application state use the persistent mounts defined by the package. Docker volumes outlive individual containers, but volume deletion still removes that data; a volume is not a backup. Redact secrets and customer data before sharing logs.
Docker: volume persistence and lifecyclePrepare PostgreSQL
Only apply this database checklist if your agreed MCP workflow uses retained data. Live source queries can have a different storage architecture.
Define the PostgreSQL database, schema, account, and storage owner. For a Windows embedded setup, identify the database service and persistent data directory created by the package.
Connection and privileges
Record whether PostgreSQL is embedded or separately managed, its version, and the connection configuration. Review the required database and schema privileges rather than granting broad administrative access by default.
Data representation
Test timestamps and time zones, numeric precision, large text, and source identifiers. Compare reference identifiers with the source and test how a changed source field appears at the destination.
Storage and recovery
Plan database capacity, growth monitoring, and database backups. For an embedded deployment, identify the data directory and verify that application upgrades or host replacement preserve it.
Check the PostgreSQL connection context
Connect to the intended archive or backup database with the application role, then run this read-only query. For embedded Windows installations, use the endpoint and port recorded by the installed package.
SQL
SELECT current_database() AS database_name,
current_user AS database_user,
current_schema() AS schema_name;
SHOW server_version;
SHOW TimeZone;What to verify
Confirm the database, role, schema, and time zone before comparing source values. For remote libpq connections, sslmode=verify-full validates both the certificate chain and hostname when the trusted CA is configured. An encrypted connection alone does not prove the server's identity.
PostgreSQL: TLS and server certificate verificationConfigure the workflow
Start with a representative dataset, then expand the scope after validation. Use the connection settings established above and keep source changes behind the appropriate approval.
Choose one useful task
Start with an example such as preparing a case summary from approved records. Define the expected output and its source evidence. Keep the initial dataset small enough for a reviewer to check the result.
Specify the access boundary
Identify the source account, permitted records, fields, and operations. A connected service account is not proof of per-user permission inheritance. Document where user identity and authorization are checked.
Review the client and tools
Configure the MCP client with the transport, authentication method, and tool access defined for your deployment. Start with read-only access where available; review any write-capable tool separately before allowing it during validation.
Test the answer and its limits
Use known questions, missing-data cases, and requests outside the approved scope. Check the source evidence, freshness, denied-access behavior, and what the client retains or sends to its model provider.
Confirm the MCP connection contract
- For stdio, the client launches a local server process. Record the executable, arguments, working directory, and how credentials enter that process. A remote URL is not a substitute for a stdio command.
- For Streamable HTTP, record the supplied MCP endpoint, TLS and authentication settings, and the client's support for that transport. Confirm the client can complete initialization and discover tools.
- Review the actual tool list against the workflow's allowlist. Start with one bounded read, then test a denied operation and a connection failure. Do not assume the client supports every transport or protocol version.
Evaluation: prepare an incident handoff
Choose a known incident and the approved fields, references, and knowledge needed for a handoff. Keep unrelated incidents and restricted fields outside the initial scope.
- Inspect the connected identity and tool list, then request a briefing for the known incident.
- Compare the briefing with source records, including missing or unavailable context.
- Request a restricted field and an out-of-scope record; confirm neither is disclosed.
- Review what the MCP host and model provider receive and retain before adding more users or data.
Scope of this example
Begin with retrieval. Any create or update tool needs an explicit permission and a separate review of business rules and side effects. A shared integration account does not establish each end user's right to see a record.
Validate before expanding
- The agent returns an answer that can be checked against the approved source data.
- Out-of-scope requests do not expose restricted records or fields.
- The effective connection identity and authorization boundary are documented.
- Tool operations, client data handling, and review responsibilities are understood.
Keep a deployment record
Record the package version, environment, data scope, test date, expected result, actual result, and owner of each unresolved issue. Keep secrets and customer data out of shared support notes.
Everyday operations
After each run
Review completion status, record counts, failures, and source API usage. Resolve unexpected differences before allowing the next dependent action.
When credentials change
Update the connection through the approved secret process, verify a bounded read, and retest the required operations. Remove obsolete credentials.
When the source changes
Review added or changed objects, fields, access rules, and automation. Repeat representative data and permission checks before expanding the scope.
Before an upgrade
Record the current package and configuration, protect persistent data, and define the rollback procedure. Validate connectivity and a representative workflow after the change.
Troubleshooting
The client cannot connect
Check the confirmed endpoint, supported transport, network reachability, and authentication configuration. Do not substitute an unverified public endpoint.
The answer is incomplete or stale
Compare the permitted dataset, filters, source freshness, and any retained copy. Distinguish unavailable data from an incorrect model interpretation.
The agent can access more than intended
Disable the connection for the initial deployment and review the service account, tool scope, and authorization boundary before reconnecting.
PostgreSQL rejects a connection or write
Check the endpoint, database name, account, TLS settings, network access policy, and schema privileges. For embedded deployments, also check process health and available disk space.
Technical references
Use these official references for the source APIs, database connection settings, and runtime behavior discussed above. They describe the underlying platforms; use your Vivly package documentation for its installation and supported configuration.
Review this deployment with Vivly
Bring your source scope, host, database, and success criteria. We will use them to identify the applicable package, open questions, and rollout sequence.
Book a demo