ServiceNow MCP Server

Overview Schema Source Related Servers Discussions Admin

Find References

find_references

Read-onlyIdempotent

Find where a ServiceNow table or field is referenced by business rules, client scripts, UI policies, ACLs, script includes, and reference fields; returns names, sys_ids, and flags only.

Instructions

Where-used for a table or one of its fields: the business rules, client scripts, UI policies, ACLs, script includes and reference fields that touch it.

Returns names, sys_ids and flags only, never script, condition or ACL bodies. Script matches (script includes; business rules and client scripts in field mode) are text matches, so expect false positives. Only this exact table is matched: run it again for a parent table (get_table_schema's hierarchy) to find rules and ACLs defined there. A source this identity can't read (403, or a 401 from an access policy that leaves its table out) is listed in not_assessable (under OAuth each such source costs one token refresh). Under basic auth the first 401 is an error (a refused password looks the same), and so is a refused OAuth secret; rows hidden by an ACL are simply missing. complete=false means the source hit the limit.

Input Schema

Name	Required	Description
`limit`	No	Maximum matches to return per source
`field_name`	No	Narrow to one field of the table (e.g., 'assigned_to')
`table_name`	Yes	The table to look up (e.g., 'incident')

Output Schema

Name	Required	Description	Default
`note`	No
`field`	No
`table`	Yes
`groups`	Yes
`truncated`	No
`not_assessable`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.9.2Oct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the readOnly/idempotent annotations, the description discloses that only names, sys_ids and flags are returned (never bodies), that script matches produce false positives, that matching is exact-table only, and that limit-truncated sources set complete=false. It also explains auth failure semantics: 401 vs 403 handling, not_assessable entries, token-refresh costs under OAuth, and that ACL-hidden rows silently vanish.

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?

Front-loaded with the core definition and the important caveats (no bodies, false positives) come next. It is dense but nearly every clause carries operational meaning; the auth/401 parenthetical is the most compressible part.

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

Completeness5/5

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

Even with an output schema present, the description covers the non-obvious parts an agent must interpret: not_assessable, complete=false, and silent ACL omissions. For a read-only, idempotent tool with rich annotations and a schema, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds genuine semantics by explaining that field_name switches business rules and client scripts into text-match "field mode", which the schema's "Narrow to one field" wording does not convey. The limit parameter's per-source semantics are left to the schema.

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?

"Where-used for a table or one of its fields" states a specific verb-equivalent and resource, then enumerates the source types scanned (business rules, client scripts, UI policies, ACLs, script includes, reference fields). This is clearly distinguishable from siblings like get_table_schema or list_records.

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?

It tells the agent to run the tool again for a parent table, pointing at get_table_schema's hierarchy, which is real routing guidance. It does not explicitly state when this tool should be skipped in favor of another sibling, so it falls short of a full when/when-not treatment.

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