Skip to main content
Glama

validate-database

validate-database

Validate Firebird database integrity by checking data and indexes, with options to fix errors and show detailed progress.

Instructions

Validates the integrity of the Firebird database

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
optionsNo

Implementation Reference

  • Registers the "validate-database" MCP tool, including its handler function that calls the core validateDatabase function and formats the response.
    // Add validate-database tool
    tools.set("validate-database", {
        name: "validate-database",
        description: "Validates the integrity of the Firebird database",
        inputSchema: ValidateDatabaseArgsSchema,
        handler: async (request) => {
            const { options } = request;
            logger.info(`Executing validate-database tool`);
    
            try {
                const result = await validateDatabase(options);
    
                return {
                    content: [{
                        type: "text",
                        text: formatForClaude(result)
                    }]
                };
            } catch (error) {
                const errorResponse = wrapError(error);
                logger.error(`Error validating database: ${errorResponse.error} [${errorResponse.errorType || 'UNKNOWN'}]`);
    
                return {
                    content: [{
                        type: "text",
                        text: formatForClaude(errorResponse)
                    }]
                };
            }
        }
    });
  • Zod input schema for the validate-database tool defining optional validation options.
    export const ValidateDatabaseArgsSchema = z.object({
        options: z.object({
            checkData: z.boolean().default(true).describe("Whether to validate data integrity"),
            checkIndexes: z.boolean().default(true).describe("Whether to validate indexes"),
            fixErrors: z.boolean().default(false).describe("Whether to attempt to fix errors"),
            verbose: z.boolean().default(false).describe("Whether to show detailed progress")
        }).optional()
    });
  • Core implementation of database validation using Firebird's gfix utility to check integrity, parse results for issues, and return validation status.
    export const validateDatabase = async (
        options: ValidateOptions = {},
        config = DEFAULT_CONFIG
    ): Promise<ValidationResult> => {
        const startTime = Date.now();
    
        try {
            // Check if Firebird tools are installed
            const toolsCheck = await checkFirebirdTools();
            if (!toolsCheck.installed) {
                throw new FirebirdError(
                    `Firebird client tools are not installed. ${toolsCheck.installInstructions}`,
                    'MISSING_FIREBIRD_TOOLS'
                );
            }
    
            // Try to find Firebird bin directory
            const firebirdBinPath = await findFirebirdBinPath();
    
            // Use GFIX for validation
            const command = firebirdBinPath ? path.join(firebirdBinPath, 'gfix') : 'gfix';
            let args: string[] = [
                '-user', config.user || 'SYSDBA',
                '-password', config.password || 'masterkey'
            ];
    
            // Add validation options
            if (options.checkData) {
                args.push('-v');  // Validate database
            }
    
            if (options.checkIndexes) {
                args.push('-i');  // Validate indexes
            }
    
            if (options.fixErrors) {
                args.push('-mend');  // Fix errors
            }
    
            // Add database path
            args.push(config.database);
    
            logger.info(`Starting database validation for ${config.database}`);
            if (options.verbose) {
                logger.debug(`Validation command: ${command} ${args.join(' ')}`);
            }
    
            // Execute the validation command
            const result = await executeCommand(command, args, options.verbose);
    
            // Parse the result to determine if the database is valid
            const issues: string[] = [];
            const lines = result.split('\n');
    
            for (const line of lines) {
                if (line.includes('error') || line.includes('corrupt') || line.includes('invalid')) {
                    issues.push(line.trim());
                }
            }
    
            const valid = issues.length === 0;
            const duration = Date.now() - startTime;
    
            logger.info(`Validation completed in ${duration}ms, valid: ${valid}, issues: ${issues.length}`);
    
            return {
                success: true,
                valid,
                issues,
                details: result
            };
        } catch (error: any) {
            const duration = Date.now() - startTime;
            const errorMessage = `Error validating database: ${error.message || error}`;
            logger.error(errorMessage);
    
            return {
                success: false,
                valid: false,
                issues: [errorMessage],
                details: error.details || '',
                error: errorMessage
            };
        }
    };
  • TypeScript interface defining the options for database validation, matching the Zod schema.
    export interface ValidateOptions {
        checkData?: boolean;
        checkIndexes?: boolean;
        fixErrors?: boolean;
        verbose?: boolean;
    }
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. It mentions 'validates integrity' but doesn't disclose critical behavioral traits: whether this is a read-only operation, potential performance impact, required permissions, output format, or error handling. For a database validation tool with zero annotation coverage, this is a significant gap.

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 gets straight to the point without unnecessary words. It's appropriately sized for the tool's apparent complexity.

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 tool's potential complexity (database validation with fixErrors option), lack of annotations, no output schema, and low schema description coverage, the description is inadequate. It doesn't explain what 'validates integrity' entails, what the tool returns, or behavioral implications of the fixErrors parameter.

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 0%, but the description provides no parameter information. The single parameter 'options' with nested boolean properties (checkData, checkIndexes, fixErrors, verbose) is completely undocumented in the description. Baseline is 3 since schema coverage is low but description doesn't compensate.

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 ('validates') and target ('integrity of the Firebird database'), which distinguishes it from siblings like backup-database or restore-database. However, it doesn't explicitly differentiate from other analysis tools like analyze-missing-indexes or system-health-check, which might also involve validation aspects.

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. With siblings like system-health-check and analyze-* tools that might overlap in diagnostic purposes, the description lacks context on appropriate use cases, prerequisites, or exclusions.

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/PuroDelphi/mcpFirebird'

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