Skip to main content
Glama

query_file_ownership

Read-only

Query file-package ownership on Arch Linux: find package for a file, list package files with optional filter, or search filenames across all packages.

Instructions

[ORGANIZATION] Unified tool for querying file-package ownership relationships. Supports three modes: 'file_to_package' (find which package owns a file), 'package_to_files' (list all files in a package with optional filtering), and 'filename_search' (search for files across all packages). Only works on Arch Linux. Examples: mode='file_to_package', query='/usr/bin/python' → returns 'python' package; mode='package_to_files', query='systemd', filter_pattern='.service' → lists all systemd service files; mode='filename_search', query='.desktop' → finds all packages with desktop entries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesQuery string: file path for file_to_package mode, package name for package_to_files mode, or filename pattern for filename_search mode
modeYesQuery mode: 'file_to_package' (find package owner), 'package_to_files' (list package files), or 'filename_search' (search across packages)
filter_patternNoOptional regex pattern to filter files (only used in package_to_files mode, e.g., '*.conf' or '/etc/')

Implementation Reference

  • Main handler function for query_file_ownership tool. Routes to find_package_owner, list_package_files, or search_package_files based on mode.
    async def query_file_ownership(
        query: str,
        mode: str,
        filter_pattern: Optional[str] = None
    ) -> Dict[str, Any]:
        """
        Unified tool for querying file ownership relationships.
        
        This consolidates three operations:
        - file_to_package: Find which package owns a specific file (replaces find_package_owner)
        - package_to_files: List all files owned by a package (replaces list_package_files)
        - filename_search: Search for files across all packages (replaces search_package_files)
    
        Args:
            query: The query string (file path, package name, or filename pattern depending on mode)
            mode: Query mode - "file_to_package", "package_to_files", or "filename_search"
            filter_pattern: Optional regex pattern to filter files (only used in package_to_files mode)
    
        Returns:
            Dict with query results appropriate to the mode
        """
        if not IS_ARCH:
            return create_error_response(
                "NotSupported",
                "File ownership queries are only available on Arch Linux"
            )
    
        if not check_command_exists("pacman"):
            return create_error_response(
                "CommandNotFound",
                "pacman command not found"
            )
    
        # Validate mode
        valid_modes = ["file_to_package", "package_to_files", "filename_search"]
        if mode not in valid_modes:
            return create_error_response(
                "ValidationError",
                f"Invalid mode '{mode}'. Must be one of: {', '.join(valid_modes)}"
            )
    
        logger.info(f"File ownership query: mode={mode}, query={query}")
    
        # Route to appropriate implementation based on mode
        if mode == "file_to_package":
            # Find which package owns a specific file (replaces find_package_owner)
            return await find_package_owner(query)
        
        elif mode == "package_to_files":
            # List all files owned by a package (replaces list_package_files)
            return await list_package_files(query, filter_pattern)
        
        elif mode == "filename_search":
            # Search for files across all packages (replaces search_package_files)
            return await search_package_files(query)
        
        # This should never be reached due to validation above
        return create_error_response(
            "InternalError",
            f"Unexpected mode: {mode}"
        )
  • Tool registration in list_tools() with input schema defining query, mode, and optional filter_pattern parameters.
    # File Ownership Query (Consolidated)
    Tool(
        name="query_file_ownership",
        description="[ORGANIZATION] Unified tool for querying file-package ownership relationships. Supports three modes: 'file_to_package' (find which package owns a file), 'package_to_files' (list all files in a package with optional filtering), and 'filename_search' (search for files across all packages). Only works on Arch Linux. Examples: mode='file_to_package', query='/usr/bin/python' → returns 'python' package; mode='package_to_files', query='systemd', filter_pattern='*.service' → lists all systemd service files; mode='filename_search', query='*.desktop' → finds all packages with desktop entries.",
        inputSchema={
            "type": "object",
            "properties": {
                "query": {
                    "type": "string",
                    "description": "Query string: file path for file_to_package mode, package name for package_to_files mode, or filename pattern for filename_search mode"
                },
                "mode": {
                    "type": "string",
                    "enum": ["file_to_package", "package_to_files", "filename_search"],
                    "description": "Query mode: 'file_to_package' (find package owner), 'package_to_files' (list package files), or 'filename_search' (search across packages)"
                },
                "filter_pattern": {
                    "type": "string",
                    "description": "Optional regex pattern to filter files (only used in package_to_files mode, e.g., '*.conf' or '/etc/')"
                }
            },
            "required": ["query", "mode"]
        },
        annotations=ToolAnnotations(readOnlyHint=True)
    ),
  • Tool dispatch in call_tool() that extracts arguments and delegates to the query_file_ownership handler.
    # File Ownership Query
    elif name == "query_file_ownership":
        if not IS_ARCH:
            return [TextContent(type="text", text=create_platform_error_message("query_file_ownership"))]
    
        query = arguments["query"]
        mode = arguments["mode"]
        filter_pattern = arguments.get("filter_pattern", None)
        result = await query_file_ownership(query, mode, filter_pattern)
        return [TextContent(type="text", text=json.dumps(result, indent=2))]
  • Tool metadata definition including category (organization), platform (arch), permission (read), and related tools.
    "query_file_ownership": ToolMetadata(
        name="query_file_ownership",
        category="organization",
        platform="arch",
        permission="read",
        workflow="debug",
        related_tools=["verify_package_integrity", "manage_groups"],
        prerequisite_tools=[]
    ),
  • Export of query_file_ownership from pacman module, making it importable as part of the package.
    from .pacman import (
        get_official_package_info,
        check_updates_dry_run,
        remove_package,
        remove_packages_batch,
        remove_packages,
        list_orphan_packages,
        remove_orphans,
        manage_orphans,
        find_package_owner,
        list_package_files,
        search_package_files,
        query_file_ownership,
Behavior5/5

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

Annotations provide readOnlyHint, and the description adds substantial behavioral details: three modes, query behavior, input format differences per mode, platform restriction. No contradictions; the description enriches the annotation's safety implication.

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 (about 85 words) yet comprehensive. It front-loads the purpose, then systematically explains each mode with examples. Every sentence contributes meaning, and the structure is clear.

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

Completeness4/5

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

With no output schema, the description provides return behavior indirectly through examples. It covers all three modes, input formats, and constraints. While the return format is not explicitly specified, the examples sufficiently convey typical outputs.

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 100%, but the description adds significant meaning beyond the schema. It explains how each parameter is used in different modes with concrete examples, clarifying the expected format and behavior beyond the basic schema descriptions.

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 the tool's purpose: querying file-package ownership relationships. It names three specific modes and uses a verb ('querying') plus resource ('file-package ownership relationships'). This distinguishes it from sibling tools, which deal with other aspects of Arch Linux package management.

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?

The description provides explicit context for each mode with examples, showing when to use each. It also notes the tool only works on Arch Linux. However, it does not explicitly state when not to use this tool or name alternatives, though sibling tools are listed for context.

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-linux-mcp'

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