Skip to main content
Glama
tarnover
by tarnover

aws_rds

Automate AWS RDS database management tasks including creating, deleting, starting, stopping, and listing instances using Ansible playbooks. Configure regions, storage, security, and backups efficiently.

Instructions

Manage AWS RDS database instances

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
allocatedStorageNo
backupRetentionPeriodNo
dbEngineNo
dbInstanceClassNo
dbInstanceIdentifierNo
dbSubnetGroupNameNo
masterPasswordNo
masterUsernameNo
multiAZNo
regionYes
skipFinalSnapshotNo
tagsNo
vpcSecurityGroupIdsNo

Implementation Reference

  • The handler function rdsOperations implements the core logic for the aws_rds tool by destructuring input args, generating an Ansible playbook based on the action (list, create, delete, start, stop), and executing it using executeAwsPlaybook.
    export async function rdsOperations(args: RDSOptions): Promise<string> {
      await verifyAwsCredentials();
    
      const { action, region, dbInstanceIdentifier, dbEngine, dbInstanceClass, allocatedStorage, masterUsername, 
        masterPassword, vpcSecurityGroupIds, dbSubnetGroupName, tags, multiAZ, backupRetentionPeriod, skipFinalSnapshot } = args;
    
      let playbookContent = `---
    - name: AWS RDS ${action} operation
      hosts: localhost
      connection: local
      gather_facts: no
      tasks:`;
      
      switch (action) {
        case 'list':
          playbookContent += `
        - name: List RDS instances
          amazon.aws.rds_instance_info:
            region: "${region}"
          register: rds_info
        
        - name: Display RDS instances
          debug:
            var: rds_info.instances`;
          break;
          
        case 'create':
          playbookContent += `
        - name: Create RDS instance
          amazon.aws.rds_instance:
            region: "${region}"
            db_instance_identifier: "${dbInstanceIdentifier}"
            engine: "${dbEngine}"
            db_instance_class: "${dbInstanceClass}"
            allocated_storage: ${allocatedStorage}
            master_username: "${masterUsername}"
            master_user_password: "${masterPassword}"
            state: present
    ${formatYamlParams({
      vpc_security_group_ids: vpcSecurityGroupIds,
      db_subnet_group_name: dbSubnetGroupName,
      tags,
      multi_az: multiAZ,
      backup_retention_period: backupRetentionPeriod,
      // Add other relevant RDS params here if needed
    })}
          register: rds_result
        
        - name: Display RDS instance details
          debug:
            var: rds_result`;
          break;
          
        case 'delete':
          playbookContent += `
        - name: Delete RDS instance
          amazon.aws.rds_instance:
            region: "${region}"
            db_instance_identifier: "${dbInstanceIdentifier}"
            state: absent
            skip_final_snapshot: ${skipFinalSnapshot ? 'yes' : 'no'}
          register: rds_delete
        
        - name: Display deletion result
          debug:
            var: rds_delete`;
          break;
          
        case 'start':
          playbookContent += `
        - name: Start RDS instance
          amazon.aws.rds_instance:
            region: "${region}"
            db_instance_identifier: "${dbInstanceIdentifier}"
            state: started
          register: rds_start
        
        - name: Display start result
          debug:
            var: rds_start`;
          break;
          
        case 'stop':
          playbookContent += `
        - name: Stop RDS instance
          amazon.aws.rds_instance:
            region: "${region}"
            db_instance_identifier: "${dbInstanceIdentifier}"
            state: stopped
          register: rds_stop
        
        - name: Display stop result
          debug:
            var: rds_stop`;
          break;
          
        default:
          throw new AnsibleError(`Unsupported RDS action: ${action}`);
      }
      
      // Execute the generated playbook
      return executeAwsPlaybook(`rds-${action}`, playbookContent);
    }
  • Zod schema RDSSchema and RDSActionEnum defining the input validation for aws_rds tool parameters including action, region, DB instance details, etc.
    export const RDSSchema = z.object({
      action: RDSActionEnum,
      region: z.string().min(1, 'AWS region is required'),
      dbInstanceIdentifier: z.string().optional(),
      dbEngine: z.string().optional(),
      dbInstanceClass: z.string().optional(),
      allocatedStorage: z.number().optional(),
      masterUsername: z.string().optional(),
      masterPassword: z.string().optional(),
      vpcSecurityGroupIds: z.array(z.string()).optional(),
      dbSubnetGroupName: z.string().optional(),
      tags: z.record(z.string()).optional(),
      multiAZ: z.boolean().optional(),
      backupRetentionPeriod: z.number().optional(),
      skipFinalSnapshot: z.boolean().optional() // Added based on usage in aws.ts
    });
    
    export type RDSOptions = z.infer<typeof RDSSchema>;
  • Registration of aws_rds tool in the toolDefinitions Record, specifying its description, input schema (aws.RDSSchema), and handler function (aws.rdsOperations).
    aws_rds: {
      description: 'Manage AWS RDS database instances',
      schema: aws.RDSSchema,
      handler: aws.rdsOperations,
    },
  • Shared helper function executeAwsPlaybook used by all AWS tools including aws_rds to dynamically execute generated Ansible playbooks in temporary directories.
    async function executeAwsPlaybook(
      operationName: string, 
      playbookContent: string, 
      extraParams: string = '',
      tempFiles: { filename: string, content: string }[] = [] // For additional files like templates, policies
    ): Promise<string> {
      let tempDir: string | undefined;
      try {
        // Create a unique temporary directory
        tempDir = await createTempDirectory(`ansible-aws-${operationName}`);
        
        // Write the main playbook file
        const playbookPath = await writeTempFile(tempDir, 'playbook.yml', playbookContent);
        
        // Write any additional temporary files
        for (const file of tempFiles) {
          await writeTempFile(tempDir, file.filename, file.content);
        }
    
        // Build the command
        const command = `ansible-playbook ${playbookPath} ${extraParams}`;
        console.error(`Executing: ${command}`);
    
        // Execute the playbook asynchronously
        const { stdout, stderr } = await execAsync(command);
        
        // Return stdout, or a success message if stdout is empty
        return stdout || `${operationName} completed successfully (no output).`;
    
      } catch (error: any) {
        // Handle execution errors
        const errorMessage = error.stderr || error.message || 'Unknown error';
        throw new AnsibleExecutionError(`Ansible execution failed for ${operationName}: ${errorMessage}`, error.stderr);
      } finally {
        // Ensure cleanup happens even if errors occur
        if (tempDir) {
          await cleanupTempDirectory(tempDir);
        }
      }
    }
Behavior2/5

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

With no annotations provided, the description carries full burden but offers minimal behavioral insight. 'Manage' implies mutation capabilities, but it doesn't disclose critical traits like authentication requirements, potential costs of create/delete actions, rate limits, or that actions like 'delete' might be irreversible. It lacks context on what 'manage' entails operationally.

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 no wasted words. It's appropriately sized for a high-level summary, though it lacks detail. The structure is front-loaded with the core purpose.

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?

For a complex tool with 14 parameters, no annotations, no output schema, and 0% schema description coverage, the description is inadequate. It doesn't explain the tool's scope, parameter meanings, behavioral expectations, or output format, leaving significant gaps for an AI agent to understand and use the tool correctly.

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

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description provides no parameter information, while the schema has 14 parameters with 0% description coverage. Parameters like 'action', 'region', 'dbInstanceIdentifier', and 'masterPassword' are undocumented in both schema and description, leaving their purposes and formats unclear. The description fails to compensate for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Manage AWS RDS database instances' states the general purpose (managing RDS instances) but is vague about what 'manage' entails. It doesn't specify the specific actions available (list, create, delete, start, stop) or distinguish this tool from sibling AWS tools like aws_ec2 or aws_s3 beyond mentioning RDS.

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. The description doesn't mention prerequisites (e.g., AWS credentials), compare to sibling tools (e.g., aws_cloudformation for infrastructure as code), or specify appropriate contexts for different actions like 'create' versus 'list'.

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/tarnover/mcp-ansible'

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