Skip to main content
Glama
vparlapalli490

ServiceNow MCP Server

update_catalog_item_variable

Modify catalog item variables in ServiceNow by updating labels, requirements, help text, default values, and display order to improve service request forms.

Instructions

Update a catalog item variable

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
variable_idYesThe sys_id of the variable to update
labelNoThe display label for the variable
mandatoryNoWhether the variable is required
help_textNoHelp text to display with the variable
default_valueNoDefault value for the variable
descriptionNoDescription of the variable
orderNoDisplay order of the variable
reference_qualifierNoFor reference fields, the query to filter reference options
max_lengthNoMaximum length for string fields
minNoMinimum value for numeric fields
maxNoMaximum value for numeric fields

Implementation Reference

  • The handler function that executes the tool logic by building a PATCH request to the ServiceNow item_option_new table API and handling the response.
    def update_catalog_item_variable(
        config: ServerConfig,
        auth_manager: AuthManager,
        params: UpdateCatalogItemVariableParams,
    ) -> CatalogItemVariableResponse:
        """
        Update an existing variable (form field) for a catalog item.
    
        Args:
            config: Server configuration.
            auth_manager: Authentication manager.
            params: Parameters for updating a catalog item variable.
    
        Returns:
            Response with information about the updated variable.
        """
        api_url = f"{config.instance_url}/api/now/table/item_option_new/{params.variable_id}"
    
        # Build request data with only parameters that are provided
        data = {}
        
        if params.label is not None:
            data["question_text"] = params.label
        if params.mandatory is not None:
            data["mandatory"] = str(params.mandatory).lower()  # ServiceNow expects "true"/"false" strings
        if params.help_text is not None:
            data["help_text"] = params.help_text
        if params.default_value is not None:
            data["default_value"] = params.default_value
        if params.description is not None:
            data["description"] = params.description
        if params.order is not None:
            data["order"] = params.order
        if params.reference_qualifier is not None:
            data["reference_qual"] = params.reference_qualifier
        if params.max_length is not None:
            data["max_length"] = params.max_length
        if params.min is not None:
            data["min"] = params.min
        if params.max is not None:
            data["max"] = params.max
    
        # If no fields to update, return early
        if not data:
            return CatalogItemVariableResponse(
                success=False,
                message="No update parameters provided",
            )
    
        # Make request
        try:
            response = requests.patch(
                api_url,
                json=data,
                headers=auth_manager.get_headers(),
                timeout=config.timeout,
            )
            response.raise_for_status()
    
            result = response.json().get("result", {})
    
            return CatalogItemVariableResponse(
                success=True,
                message="Catalog item variable updated successfully",
                variable_id=params.variable_id,
                details=result,
            )
    
        except requests.RequestException as e:
            logger.error(f"Failed to update catalog item variable: {e}")
            return CatalogItemVariableResponse(
                success=False,
                message=f"Failed to update catalog item variable: {str(e)}",
            ) 
  • Pydantic model defining the input parameters for the update_catalog_item_variable tool.
    class UpdateCatalogItemVariableParams(BaseModel):
        """Parameters for updating a catalog item variable."""
    
        variable_id: str = Field(..., description="The sys_id of the variable to update")
        label: Optional[str] = Field(None, description="The display label for the variable")
        mandatory: Optional[bool] = Field(None, description="Whether the variable is required")
        help_text: Optional[str] = Field(None, description="Help text to display with the variable")
        default_value: Optional[str] = Field(None, description="Default value for the variable")
        description: Optional[str] = Field(None, description="Description of the variable")
        order: Optional[int] = Field(None, description="Display order of the variable")
        reference_qualifier: Optional[str] = Field(None, description="For reference fields, the query to filter reference options")
        max_length: Optional[int] = Field(None, description="Maximum length for string fields")
        min: Optional[int] = Field(None, description="Minimum value for numeric fields")
        max: Optional[int] = Field(None, description="Maximum value for numeric fields")
  • Registration of the tool in the central tool definitions dictionary used by the MCP server, mapping name to handler, schema, description, etc.
    "update_catalog_item_variable": (
        update_catalog_item_variable_tool,
        UpdateCatalogItemVariableParams,
        Dict[str, Any],  # Expects dict
        "Update a catalog item variable",
        "dict",  # Tool returns Pydantic model
    ),
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Update' implies a mutation operation, but the description doesn't mention permission requirements, whether changes are reversible, side effects, or what happens to unspecified fields. For an 11-parameter mutation tool with zero annotation coverage, this is a significant gap in safety and operational context.

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?

The description is a single, efficient sentence with zero waste. It's appropriately sized for a tool where detailed information is provided in the schema, though this conciseness comes at the cost of missing contextual guidance. Every word earns its place by stating the core action and resource.

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

Completeness2/5

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

Given the complexity (11 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or response format. For a mutation tool with rich parameters but no structured safety hints, the description should provide more operational context to compensate.

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%, with each parameter well-documented in the schema (e.g., 'variable_id' as sys_id, 'label' as display label). The description adds no parameter information beyond the schema, not even hinting at the scope of updatable fields. Baseline 3 is appropriate since the schema does all the heavy lifting for parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Update a catalog item variable' clearly states the action (update) and resource (catalog item variable), but it's quite generic. It doesn't specify what aspects can be updated or differentiate from sibling tools like 'update_catalog_category' or 'update_article' beyond the resource type. The purpose is understandable but lacks specificity about scope.

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?

The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'create_catalog_item_variable' and 'list_catalog_item_variables', there's no indication of prerequisites, dependencies, or appropriate contexts for updating versus creating or listing. The agent must infer usage from the tool name alone.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vparlapalli490/MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server