Skip to main content
Glama

Get problems

servicenow_get_problems
Read-onlyIdempotent

Retrieve and filter ServiceNow problem records by query, fields, limit, and offset to review problem details.

Instructions

Retrieve details of problem records.

: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 ParameterError: If input parameters are invalid.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataNo
problem_idNo
sysparm_viewNo
sysparm_limitNo
sysparm_queryNo
api_parametersNo
sysparm_fieldsNo
sysparm_offsetNo
name_value_pairsNo
sysparm_no_countNo
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.1/5.0
Behavior3/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 fully covered. The description adds that it raises ParameterError on invalid input and returns parsed Pydantic models, which is modest additional context. It does not discuss pagination behavior despite pagination-related params, so added value is limited.

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 purpose sentence is front-loaded, which is good, but the body is a long type-annotated docstring param dump. Given no schema descriptions exist, this content is largely functional rather than filler, but the :type/:param repetition adds bulk without much semantic depth.

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 15-parameter read tool with no output schema, the description should do more: it never explains the undocumented problem_id/data/api_parameters, gives only a one-line return statement, and offers no pagination guidance. It is minimally adequate but leaves real gaps.

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 0%, so the description must carry the load, and it does document ~12 of 15 params with intent and types. But three schema params (data, problem_id, api_parameters) are undocumented anywhere, and many documented descriptions merely restate the parameter name (e.g., sysparm_limit 'Maximum number of records to return'). Partial compensation warrants a 3.

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?

States a specific verb+resource ('Retrieve details of problem records'), which is clear on its own. However, it does not distinguish itself from the very similar sibling servicenow_get_problem (singular), nor does it clarify that this returns a collection rather than a single record. Clear, but missing sibling differentiation keeps it from a 5.

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 guidance on when to use this tool versus servicenow_get_problem, create_problem, delete_problem, or the generic get_table_record/get_table tools. No prerequisites or filtering context is implied beyond the param docstring. Effectively no usage guidance.

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