Skip to main content
Glama

validate_excel_range

Check and verify the existence and formatting of a specific cell range in an Excel file. Ensure data integrity by validating sheet names, start cells, and optional end cells.

Instructions

Validate if a range exists and is properly formatted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
end_cellNo
filepathYes
sheet_nameYes
start_cellYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The MCP tool handler for 'validate_excel_range'. This function is decorated with @mcp.tool() for registration and executes the validation logic by delegating to the validate_range_impl helper.
    @mcp.tool()
    def validate_excel_range(
        filepath: str,
        sheet_name: str,
        start_cell: str,
        end_cell: Optional[str] = None
    ) -> str:
        """Validate if a range exists and is properly formatted."""
        try:
            full_path = get_excel_path(filepath)
            range_str = start_cell if not end_cell else f"{start_cell}:{end_cell}"
            result = validate_range_impl(full_path, sheet_name, range_str)
            return result["message"]
        except ValidationError as e:
            return f"Error: {str(e)}"
        except Exception as e:
            logger.error(f"Error validating range: {e}")
            raise
  • Core helper function implementing the range validation logic. Checks sheet existence, parses range, validates bounds against worksheet dimensions, and returns detailed validation info. This is called by the handler as validate_range_impl.
    def validate_range_in_sheet_operation(
        filepath: str,
        sheet_name: str,
        start_cell: str,
        end_cell: str | None = None,
    ) -> dict[str, Any]:
        """Validate if a range exists in a worksheet and return data range info."""
        try:
            wb = load_workbook(filepath)
            if sheet_name not in wb.sheetnames:
                raise ValidationError(f"Sheet '{sheet_name}' not found")
                
            worksheet = wb[sheet_name]
            
            # Get actual data dimensions
            data_max_row = worksheet.max_row
            data_max_col = worksheet.max_column
            
            # Validate range
            try:
                start_row, start_col, end_row, end_col = parse_cell_range(start_cell, end_cell)
            except ValueError as e:
                raise ValidationError(f"Invalid range: {str(e)}")
                
            # If end not specified, use start
            if end_row is None:
                end_row = start_row
            if end_col is None:
                end_col = start_col
                
            # Validate bounds against maximum possible Excel limits
            is_valid, message = validate_range_bounds(
                worksheet, start_row, start_col, end_row, end_col
            )
            if not is_valid:
                raise ValidationError(message)
                
            range_str = f"{start_cell}" if end_cell is None else f"{start_cell}:{end_cell}"
            data_range_str = f"A1:{get_column_letter(data_max_col)}{data_max_row}"
            
            # Check if range is within data or extends beyond
            extends_beyond_data = (
                end_row > data_max_row or 
                end_col > data_max_col
            )
            
            return {
                "message": (
                    f"Range '{range_str}' is valid. "
                    f"Sheet contains data in range '{data_range_str}'"
                ),
                "valid": True,
                "range": range_str,
                "data_range": data_range_str,
                "extends_beyond_data": extends_beyond_data,
                "data_dimensions": {
                    "max_row": data_max_row,
                    "max_col": data_max_col,
                    "max_col_letter": get_column_letter(data_max_col)
                }
            }
        except ValidationError as e:
            logger.error(str(e))
            raise
        except Exception as e:
            logger.error(f"Failed to validate range: {e}")
            raise ValidationError(str(e))
  • Supporting helper function used by the main validation logic to check if the specified range bounds are within the worksheet's max_row and max_column.
    def validate_range_bounds(
        worksheet: Worksheet,
        start_row: int,
        start_col: int,
        end_row: int | None = None,
        end_col: int | None = None,
    ) -> tuple[bool, str]:
        """Validate that cell range is within worksheet bounds"""
        max_row = worksheet.max_row
        max_col = worksheet.max_column
    
        try:
            # Check start cell bounds
            if start_row < 1 or start_row > max_row:
                return False, f"Start row {start_row} out of bounds (1-{max_row})"
            if start_col < 1 or start_col > max_col:
                return False, (
                    f"Start column {get_column_letter(start_col)} "
                    f"out of bounds (A-{get_column_letter(max_col)})"
                )
    
            # If end cell specified, check its bounds
            if end_row is not None and end_col is not None:
                if end_row < start_row:
                    return False, "End row cannot be before start row"
                if end_col < start_col:
                    return False, "End column cannot be before start column"
                if end_row > max_row:
                    return False, f"End row {end_row} out of bounds (1-{max_row})"
                if end_col > max_col:
                    return False, (
                        f"End column {get_column_letter(end_col)} "
                        f"out of bounds (A-{get_column_letter(max_col)})"
                    )
    
            return True, "Range is valid"
        except Exception as e:
            return False, f"Invalid range: {e!s}"
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 mentions validation but doesn't specify what 'properly formatted' means (e.g., cell references, non-empty cells), what happens on failure (e.g., error messages, return values), or whether it modifies the file. This leaves significant gaps in understanding the tool's behavior.

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 wasted words. It's front-loaded with the core purpose and appropriately sized for the tool's apparent complexity, making it easy to parse quickly.

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?

Given the tool has an output schema (which should cover return values), the description's minimalism is somewhat acceptable. However, with 4 parameters at 0% schema coverage and no annotations, it lacks sufficient context for safe and effective use, especially for a validation tool that likely has specific input requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/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 compensate but adds no parameter information. It doesn't explain what 'filepath', 'sheet_name', 'start_cell', or 'end_cell' represent, their formats (e.g., A1 notation for cells), or how they interact. This fails to address the undocumented parameters.

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 tool's purpose with a specific verb ('validate') and resource ('excel range'), and distinguishes it from siblings like 'validate_formula_syntax' by focusing on range existence and formatting. However, it doesn't explicitly mention Excel files, which could be inferred from context but isn't stated directly.

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 like 'read_data_from_excel' or 'get_merged_cells', nor does it mention prerequisites such as file accessibility or sheet existence. It simply states what the tool does without contextual usage information.

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

Related 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/haris-musa/excel-mcp-server'

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