Skip to main content
Glama
javerthl

ServiceNow MCP Server

by javerthl

move_catalog_items

Move ServiceNow catalog items from one category to another by specifying item IDs and target category ID to reorganize the service catalog structure.

Instructions

Move catalog items to a different category.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
item_idsYesList of catalog item IDs to move
target_category_idYesTarget category ID to move items to

Implementation Reference

  • The handler function that implements the move_catalog_items tool. It updates the 'category' field of each specified catalog item via PATCH requests to the ServiceNow sc_cat_item table API, handling multiple items and reporting successes/failures.
    def move_catalog_items(
        config: ServerConfig,
        auth_manager: AuthManager,
        params: MoveCatalogItemsParams,
    ) -> CatalogResponse:
        """
        Move catalog items to a different category.
    
        Args:
            config: Server configuration
            auth_manager: Authentication manager
            params: Parameters for moving catalog items
    
        Returns:
            Response containing the result of the operation
        """
        logger.info(f"Moving {len(params.item_ids)} catalog items to category: {params.target_category_id}")
        
        # Build the API URL
        url = f"{config.instance_url}/api/now/table/sc_cat_item"
        
        # Make the API request for each item
        headers = auth_manager.get_headers()
        headers["Accept"] = "application/json"
        headers["Content-Type"] = "application/json"
        
        success_count = 0
        failed_items = []
        
        try:
            for item_id in params.item_ids:
                item_url = f"{url}/{item_id}"
                body = {
                    "category": params.target_category_id
                }
                
                try:
                    response = requests.patch(item_url, headers=headers, json=body)
                    response.raise_for_status()
                    success_count += 1
                except requests.exceptions.RequestException as e:
                    logger.error(f"Error moving catalog item {item_id}: {str(e)}")
                    failed_items.append({"item_id": item_id, "error": str(e)})
            
            # Prepare the response
            if success_count == len(params.item_ids):
                return CatalogResponse(
                    success=True,
                    message=f"Successfully moved {success_count} catalog items to category {params.target_category_id}",
                    data={"moved_items_count": success_count},
                )
            elif success_count > 0:
                return CatalogResponse(
                    success=True,
                    message=f"Partially moved catalog items. {success_count} succeeded, {len(failed_items)} failed.",
                    data={
                        "moved_items_count": success_count,
                        "failed_items": failed_items,
                    },
                )
            else:
                return CatalogResponse(
                    success=False,
                    message="Failed to move any catalog items",
                    data={"failed_items": failed_items},
                )
        
        except Exception as e:
            logger.error(f"Error moving catalog items: {str(e)}")
            return CatalogResponse(
                success=False,
                message=f"Error moving catalog items: {str(e)}",
                data=None,
            ) 
  • Pydantic BaseModel defining the input parameters for the move_catalog_items tool: a list of item IDs and the target category ID.
    class MoveCatalogItemsParams(BaseModel):
        """Parameters for moving catalog items between categories."""
        
        item_ids: List[str] = Field(..., description="List of catalog item IDs to move")
        target_category_id: str = Field(..., description="Target category ID to move items to")
  • Tool registration in get_tool_definitions() dictionary, mapping the tool name to its handler function alias, params schema, return type hint, description, and serialization method.
    "move_catalog_items": (
        move_catalog_items_tool,
        MoveCatalogItemsParams,
        str,  # Expects JSON string
        "Move catalog items to a different category.",
        "json_dict",  # Tool returns Pydantic model
    ),
  • Import of the move_catalog_items function from catalog_tools.py into the tools package namespace.
    move_catalog_items,
  • Inclusion of move_catalog_items in the __all__ list for public export from the tools package.
    "move_catalog_items",
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is a 'move', implying mutation, but doesn't cover critical aspects like permissions required, whether the operation is reversible, effects on item references or dependencies, error handling, or response format. This leaves significant gaps for a tool that modifies data.

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 that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse quickly. Every part of the sentence contributes essential information.

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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., side effects, permissions), usage context, and what to expect upon success or failure. Given the complexity of moving items between categories, more guidance is needed to ensure safe and correct use.

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%, so the schema already documents both parameters ('item_ids' and 'target_category_id') with clear descriptions. The description adds no additional meaning beyond implying that items are moved as a batch to a single category, which is already inferred from the parameter names and schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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?

The description clearly states the action ('move') and resource ('catalog items'), specifying the destination ('to a different category'). It distinguishes from siblings like 'update_catalog_item' or 'create_catalog_category' by focusing on relocation rather than modification or creation. However, it doesn't explicitly differentiate from potential similar tools like 'reorder_catalog_items' or 'transfer_catalog_items' if they existed.

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?

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention prerequisites (e.g., items must exist, target category must be valid), or contrast with tools like 'update_catalog_item' for changing other properties. The description lacks context about use cases or limitations.

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/javerthl/servicenow-mcp'

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