Skip to main content
Glama

check_updates_dry_run

Read-only

Check for pending system updates on Arch Linux without applying them. Displays upgrade packages and sizes for safe review before updating.

Instructions

[LIFECYCLE] Check for available system updates without applying them. Only works on Arch Linux systems. Requires pacman-contrib package. Safe read-only operation that shows pending updates. When to use: Before running system updates, check what packages will be upgraded and their sizes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Core handler function for check_updates_dry_run. Checks for Arch Linux, validates checkupdates command exists, runs 'checkupdates', parses output, and returns list of available updates or error responses.
    async def check_updates_dry_run() -> Dict[str, Any]:
        """
        Check for available system updates without applying them.
        
        Only works on Arch Linux systems with checkupdates command.
        Requires pacman-contrib package.
        
        Returns:
            Dict with list of available updates or error response
        """
        logger.info("Checking for system updates (dry run)")
        
        # Only supported on Arch Linux
        if not IS_ARCH:
            return create_error_response(
                "NotSupported",
                "Update checking is only supported on Arch Linux systems",
                "This server is not running on Arch Linux"
            )
        
        # Check if checkupdates command exists
        if not check_command_exists("checkupdates"):
            return create_error_response(
                "CommandNotFound",
                "checkupdates command not found",
                "Install pacman-contrib package: pacman -S pacman-contrib"
            )
        
        try:
            exit_code, stdout, stderr = await run_command(
                ["checkupdates"],
                timeout=30,  # Can take longer for sync
                check=False
            )
            
            # Exit code 0: updates available
            # Exit code 2: no updates available
            # Other: error
            
            if exit_code == 2 or not stdout.strip():
                logger.info("No updates available")
                return {
                    "updates_available": False,
                    "count": 0,
                    "packages": []
                }
            
            if exit_code != 0:
                logger.error(f"checkupdates failed with code {exit_code}: {stderr}")
                return create_error_response(
                    "CommandError",
                    f"checkupdates command failed: {stderr}",
                    f"Exit code: {exit_code}"
                )
            
            # Parse checkupdates output
            updates = _parse_checkupdates_output(stdout)
            
            logger.info(f"Found {len(updates)} available updates")
            
            return {
                "updates_available": True,
                "count": len(updates),
                "packages": updates
            }
            
        except Exception as e:
            logger.error(f"Update check failed: {e}")
            return create_error_response(
                "UpdateCheckError",
                f"Failed to check for updates: {str(e)}"
            )
  • Helper function that parses the raw output from the checkupdates command, extracting package name, current version, and new version using regex.
    def _parse_checkupdates_output(output: str) -> List[Dict[str, str]]:
        """
        Parse checkupdates command output.
        
        Format: "package current_version -> new_version"
        
        Args:
            output: Raw checkupdates output
        
        Returns:
            List of update dicts
        """
        updates = []
        
        for line in output.strip().split('\n'):
            if not line.strip():
                continue
            
            # Match pattern: "package old_ver -> new_ver"
            match = re.match(r'^(\S+)\s+(\S+)\s+->\s+(\S+)$', line)
            if match:
                updates.append({
                    "package": match.group(1),
                    "current_version": match.group(2),
                    "new_version": match.group(3)
                })
        
        return updates
  • Tool registration in list_tools() - defines the tool name, description, empty input schema, and read-only annotation for the MCP server.
    Tool(
        name="check_updates_dry_run",
        description="[LIFECYCLE] Check for available system updates without applying them. Only works on Arch Linux systems. Requires pacman-contrib package. Safe read-only operation that shows pending updates. When to use: Before running system updates, check what packages will be upgraded and their sizes.",
        inputSchema={
            "type": "object",
            "properties": {}
        },
        annotations=ToolAnnotations(readOnlyHint=True)
    ),
  • Tool dispatch in call_tool() - routes the 'check_updates_dry_run' tool name to the actual handler, with platform check.
    elif name == "check_updates_dry_run":
        if not IS_ARCH:
            return [TextContent(type="text", text=create_platform_error_message("check_updates_dry_run"))]
        
        result = await check_updates_dry_run()
        return [TextContent(type="text", text=json.dumps(result, indent=2))]
  • Tool metadata definition: marks the tool as category='lifecycle', platform='arch', permission='read', workflow='update' with related tools.
    "check_updates_dry_run": ToolMetadata(
        name="check_updates_dry_run",
        category="lifecycle",
        platform="arch",
        permission="read",
        workflow="update",
        related_tools=["check_critical_news", "check_disk_space"],
        prerequisite_tools=[]
    ),
Behavior5/5

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

Annotations already declare readOnlyHint=true, and the description adds 'Safe read-only operation' to reinforce this. It also includes lifecycle indicator [LIFECYCLE] and system requirements, providing additional behavioral context beyond annotations.

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 concise with three sentences, each adding value: purpose, system requirements, and usage guidance. It is front-loaded with the lifecycle tag and contains no wasted words.

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?

Despite no output schema, the description explains what the tool shows (pending updates with package sizes). For a no-parameter tool on a specific system, it provides sufficient completeness for an agent to use correctly.

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?

There are no parameters, so the baseline is 4. The description does not need to add parameter information, and it appropriately focuses on the tool's purpose.

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?

The description clearly states it checks for available system updates without applying them. Verb 'check' and resource 'system updates' are specific, and the 'dry run' concept distinguishes it from sibling tools like install_package_secure or remove_packages.

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?

It explicitly says 'Before running system updates, check what packages will be upgraded and their sizes,' providing a clear when-to-use context. It also specifies it only works on Arch Linux and requires pacman-contrib. While it doesn't mention when not to use or alternatives, the context is sufficient.

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/nihalxkumar/arch-mcp'

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