ServiceNow_Developer_Panel

Overview Schema Source Related Servers Discussions Admin

verify_acl

Read-onlyIdempotent

Check whether role profiles can run an operation on a table or field according to ServiceNow ACLs, returning each profile's decision, reasons, and involved controls.

Instructions

Check whether users holding the given sets of roles can run an operation on a table, or on one of its fields, according to the ACLs of the instance. Each profile gets a decision (allowed, conditional, denied or missing), a summary, the reasons and the controls involved. Scripts and conditions are not run: conditional means the scripts and conditions listed in the controls decide. The controls also show which roles each ACL requires. Parent table inheritance is not evaluated: missing means no ACL matched.

Input Schema

Name	Required	Description
`field`	No	Optional field name, to verify field level controls. Only for the read and update operations.
`table`	Yes	ServiceNow table name, for example incident or sys_user.
`refresh`	No	Skip the local cache and ask the instance again. Leave false to reuse a recent response.
`instance`	Yes	Name of a configured instance, as returned by list_instances.
`profiles`	Yes	One list of role names per user to check, for example [["itil", "snc_internal"], ["admin"]]. List every role the user holds, including snc_internal and the roles contained in other roles: none is added automatically. A user passes a control when any of its roles is required by the control. Empty lists are ignored. Roles are compared locally and never sent to the instance.
`operation`	Yes	The operation to verify.

Output Schema

Name	Required	Description	Default
`field`	Yes
`table`	Yes
`source`	Yes
`target`	Yes
`profiles`	Yes
`acl_names`	Yes
`operation`	Yes
`cache_name`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only declare readOnly/openWorld/idempotent; the description goes well beyond them by disclosing that scripts and conditions are never run, that 'conditional' means the listed controls decide, that 'missing' means no ACL matched rather than an inherited denial, and that the controls reveal which roles each ACL requires. These are exactly the interpretation caveats an agent needs to avoid misreading the result.

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

Conciseness5/5

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

Four tight sentences: purpose first, then output shape, then the two interpretive caveats. No repetition of the tool name, no filler, and each sentence carries information an agent would otherwise have to guess.

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?

For a 6-parameter, read-only verification tool with an output schema, the description covers the remaining interpretive burden: what each decision value means and the two evaluation boundaries (no script execution, no parent inheritance). Nothing needed to call it or interpret it correctly appears to be missing.

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 100%, and the schema already explains profiles nesting, the field's read/update restriction, refresh caching, and instance sourcing. The description adds no parameter-level detail beyond the schema; its added meaning is about outcome semantics (allowed/conditional/denied/missing), not the inputs. Baseline 3 applies.

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 and resource: 'Check whether users holding the given sets of roles can run an operation on a table, or on one of its fields, according to the ACLs of the instance.' No sibling tool (list_instances, describe_table, request_table, query_cache...) performs ACL evaluation, so the scope is unambiguous even without naming an alternative.

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?

The description makes clear what question the tool answers and flags two important scoping limits that determine whether its answer applies: scripts and conditions are not executed, and parent table inheritance is not evaluated. It stops short of explicitly naming sibling tools or stating when to prefer them, so it is strong context rather than full routing guidance.

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

Deploy Server