Skip to main content
Glama
LawrenceCirillo

QuickBase MCP Server

quickbase_validate_relationship

Verify integrity of QuickBase table relationships by validating foreign key links between parent and child tables to ensure data consistency and accuracy.

Instructions

Validate the integrity of a table relationship

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
childTableIdYesChild table ID
foreignKeyFieldIdYesForeign key field ID to validate
parentTableIdYesParent table ID

Implementation Reference

  • The core handler function that executes the tool logic: validates relationship integrity by checking if parent/child tables exist, if the foreign key field is a reference field, and scans child records for orphaned ones where foreign key values don't correspond to existing parent records.
    async validateRelationship(
      parentTableId: string,
      childTableId: string,
      foreignKeyFieldId: number
    ): Promise<{ isValid: boolean; issues: string[]; orphanedRecords: number }> {
      const issues: string[] = [];
      let orphanedRecords = 0;
    
      try {
        // Check if parent table exists
        await this.getTableInfo(parentTableId);
      } catch (error) {
        issues.push(`Parent table ${parentTableId} not found`);
      }
    
      try {
        // Check if child table exists
        await this.getTableInfo(childTableId);
      } catch (error) {
        issues.push(`Child table ${childTableId} not found`);
      }
    
      try {
        // Check if foreign key field exists
        const childFields = await this.getTableFields(childTableId);
        const foreignKeyField = childFields.find(field => field.id === foreignKeyFieldId);
        if (!foreignKeyField) {
          issues.push(`Foreign key field ${foreignKeyFieldId} not found in child table`);
        } else if (foreignKeyField.fieldType !== 'reference') {
          issues.push(`Field ${foreignKeyFieldId} is not a reference field`);
        }
    
        // Check for orphaned records (child records with invalid parent references)
        const childRecords = await this.getRecords(childTableId, {
          select: [3, foreignKeyFieldId], // Record ID and foreign key
          where: `{${foreignKeyFieldId}.XEX.''}`
        });
    
        for (const record of childRecords) {
          const foreignKeyValue = record[foreignKeyFieldId]?.value;
          if (foreignKeyValue) {
            try {
              await this.getRecord(parentTableId, foreignKeyValue);
            } catch (error) {
              orphanedRecords++;
            }
          }
        }
    
           } catch (error) {
         issues.push(`Error validating relationship: ${error instanceof Error ? error.message : 'Unknown error'}`);
       }
    
      return {
        isValid: issues.length === 0 && orphanedRecords === 0,
        issues,
        orphanedRecords
      };
    }
  • Registers the 'quickbase_validate_relationship' tool in the MCP tools array with its name, description, and JSON input schema.
    {
      name: 'quickbase_validate_relationship',
      description: 'Validate the integrity of a table relationship',
      inputSchema: {
        type: 'object',
        properties: {
          parentTableId: { type: 'string', description: 'Parent table ID' },
          childTableId: { type: 'string', description: 'Child table ID' },
          foreignKeyFieldId: { type: 'number', description: 'Foreign key field ID to validate' }
        },
        required: ['parentTableId', 'childTableId', 'foreignKeyFieldId']
      }
    },
  • Zod schema for input validation of the tool parameters: parentTableId, childTableId, foreignKeyFieldId.
    const ValidateRelationshipSchema = z.object({
      parentTableId: z.string().describe('Parent table ID'),
      childTableId: z.string().describe('Child table ID'),
      foreignKeyFieldId: z.number().describe('Foreign key field ID to validate')
    });
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool validates relationship integrity but doesn't explain what this entails (e.g., checks for orphaned records, referential integrity violations), what happens during validation (read-only operation, potential performance impact), or what output to expect (validation report, error list). This is inadequate for a validation tool with zero annotation coverage.

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's appropriately sized and front-loaded, with every word earning its place. No structural issues or redundancy are present.

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 complexity of relationship validation, no annotations, and no output schema, the description is insufficient. It doesn't explain what 'integrity' means in this context, what validation checks are performed, what the output looks like, or potential side effects. For a diagnostic/validation tool with zero structured metadata, more descriptive context is needed.

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 all three parameters (parentTableId, childTableId, foreignKeyFieldId) with clear descriptions. The tool description adds no additional parameter semantics beyond what's in the schema, such as explaining how these IDs relate to each other or validation specifics. Baseline 3 is appropriate when 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 tool's purpose as 'Validate the integrity of a table relationship', which is a specific verb+resource combination. It distinguishes itself from sibling tools like quickbase_get_relationship_details (which retrieves details) and quickbase_create_relationship (which creates relationships), but doesn't explicitly differentiate from all siblings in the validation context.

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. It doesn't mention prerequisites (e.g., when relationship validation is needed), exclusions, or compare it to related tools like quickbase_get_relationship_details for diagnostic purposes. Usage context is implied but not stated.

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/LawrenceCirillo/QuickBase-MCP-Server'

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