Skip to main content
Glama

Get table

servicenow_get_table
Read-onlyIdempotent

Retrieve records from a ServiceNow table using filters, field selection, and pagination. Use parameters like table name and query to fetch specific data.

Instructions

Get records from the specified table based on provided parameters.

:param table: The name of the table. :type table: str :param name_value_pairs: Dictionary of name-value pairs for filtering records. :type name_value_pairs: str :param sysparm_display_value: Display values for reference fields ('True', 'False', or 'all'). :type sysparm_display_value: str :param sysparm_exclude_reference_link: Exclude reference links in the response. :type sysparm_exclude_reference_link: bool :param sysparm_fields: Comma-separated list of field names to include in the response. :type sysparm_fields: str :param sysparm_limit: Maximum number of records to return. :type sysparm_limit: int :param sysparm_no_count: Do not include the total number of records in the response. :type sysparm_no_count: bool :param sysparm_offset: Number of records to skip before starting the retrieval. :type sysparm_offset: int :param sysparm_query: Encoded query string for filtering records. :type sysparm_query: str :param sysparm_query_category: Category to which the query belongs. :type sysparm_query_category: str :param sysparm_query_no_domain: Exclude records based on domain separation. :type sysparm_query_no_domain: bool :param sysparm_suppress_pagination_header: Suppress pagination headers in the response. :type sysparm_suppress_pagination_header: bool :param sysparm_view: Display style ('desktop', 'mobile', or 'both'). :type sysparm_view: str

:return: Response containing list of parsed Pydantic models with information about the retrieved records. :rtype: Response

:raises MissingParameterError: If table is not provided. :raises ParameterError: If input parameters are invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
tableNo
sysparm_viewNo
sysparm_limitNo
sysparm_queryNo
api_parametersNo
sysparm_fieldsNo
sysparm_offsetNo
name_value_pairsNo
sysparm_no_countNo
table_record_sys_idNo
sysparm_display_valueNo
sysparm_query_categoryNo
sysparm_query_no_domainNo
sysparm_exclude_reference_linkNo
sysparm_suppress_pagination_headerNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.4.0

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that: the return shape (parsed Pydantic models) and the raised exceptions (MissingParameterError, ParameterError). Minor inconsistency: it says MissingParameterError fires when table is absent, yet the schema marks table as optional with a null default.

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?

The opening purpose sentence is properly front-loaded, but the body is a long Sphinx-style dump where each parameter consumes two lines, and the :type: lines largely restate information already expressed by the JSON schema types. Reasonably organized but with redundant scaffolding.

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

Completeness3/5

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

For a 16-parameter query tool with no output schema, the description covers most parameters, the return type, and error behavior, and annotations cover safety. It still omits the role of data/api_parameters/table_record_sys_id and does not clarify how name_value_pairs relates to sysparm_query, leaving meaningful ambiguity for an agent building a query.

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 description coverage is 0%, so the description carries the full burden and does so for 13 of 16 parameters, adding semantic hints beyond bare types (display_value accepts 'True'/'False'/'all', fields is comma-separated, offset skips records, query is an encoded query string). It leaves data, api_parameters, and table_record_sys_id entirely unexplained, so it does not fully close the 0% gap.

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?

"Get records from the specified table" gives a specific verb (get) and resource (table records), and the plural "records" hints at a list rather than the single-record servicenow_get_table_record sibling. However, it never names or distinguishes itself from that close sibling, so an agent must infer the split without help.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no stated prerequisites, and no alternative tools named. With close siblings like servicenow_get_table_record, servicenow_get_cmdb, and servicenow_api_request in the namespace, the absence of routing guidance is a real gap.

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