Skip to main content
Glama

update_config

Modify TOYBOX configuration settings including title, theme, layout, and display options to customize your GitHub Pages portfolio site.

Instructions

Update TOYBOX configuration (title, theme, layout, etc.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configYes

Implementation Reference

  • Main handler function that implements the update_config tool: finds the local TOYBOX repo, updates config file via ArtifactService, commits and pushes Git changes, returns success result with summary.
    export async function updateConfig(configUpdates: Partial<ToyboxConfig>): Promise<UpdateConfigResult> {
      try {
        // Step 1: Find local TOYBOX repository
        log.info('Looking for local TOYBOX repository');
        const localPath = await findToyboxRepository();
        
        if (!localPath) {
          return {
            success: false,
            config: {} as ToyboxConfig,
            error: 'No TOYBOX repository found. Please run initialize_toybox first.',
          };
        }
    
        log.info('Found TOYBOX at path', { localPath });
    
        // Step 2: Initialize services
        const gitService = new GitService(localPath);
        const artifactService = new ArtifactService(localPath);
    
        // Step 3: Read current configuration
        const currentConfig = await artifactService.readConfig();
        
        // Step 4: Update configuration
        log.info('Updating configuration');
        await artifactService.updateConfig(configUpdates);
        
        // Step 5: Read updated configuration
        const updatedConfig = await artifactService.readConfig();
    
        // Step 6: Commit changes if there are any
        log.info('Committing configuration changes');
        
        // Pull latest changes first
        try {
          await gitService.pull();
        } catch (error) {
          log.warn('Could not pull changes, proceeding with local state');
        }
    
        // Stage configuration file
        await gitService.addFiles(['TOYBOX_CONFIG.json']);
    
        // Check if there are changes to commit
        const hasChanges = await gitService.hasUncommittedChanges();
        if (hasChanges) {
          const commitMessage = `feat: Update TOYBOX configuration\\n\\n` +
                               `Configuration changes:\\n` +
                               Object.entries(configUpdates)
                                 .map(([key, value]) => `- ${key}: ${JSON.stringify(value)}`)
                                 .join('\\n');
    
          await gitService.commit(commitMessage);
          await gitService.push();
        }
    
        // Step 7: Format changes summary
        const changes = Object.entries(configUpdates)
          .filter(([key, value]) => currentConfig[key as keyof ToyboxConfig] !== value)
          .map(([key, value]) => `• ${key}: ${JSON.stringify(currentConfig[key as keyof ToyboxConfig])} → ${JSON.stringify(value)}`)
          .join('\\n');
    
        return {
          success: true,
          config: updatedConfig,
          message: `✅ TOYBOX configuration updated successfully!\\n\\n` +
                   `Changes:\\n${changes || 'No changes detected'}\\n\\n` +
                   `Current configuration:\\n` +
                   `• Title: ${updatedConfig.title}\\n` +
                   `• Description: ${updatedConfig.description}\\n` +
                   `• Theme: ${updatedConfig.theme}\\n` +
                   `• Layout: ${updatedConfig.layout}\\n` +
                   `• Show Footer: ${updatedConfig.showFooter}\\n\\n` +
                   `Your changes will be visible on the next site deployment.`,
        };
    
      } catch (error) {
        const errorMessage = error instanceof Error ? error.message : String(error);
        
        return {
          success: false,
          config: {} as ToyboxConfig,
          error: `Failed to update configuration: ${errorMessage}`,
        };
      }
    }
  • src/index.ts:168-186 (registration)
    Tool registration in ListToolsRequestSchema handler, defining name, description, and input schema.
      name: 'update_config',
      description: 'Update TOYBOX configuration (title, theme, layout, etc.)',
      inputSchema: {
        type: 'object',
        properties: {
          config: {
            type: 'object',
            properties: {
              title: { type: 'string' },
              description: { type: 'string' },
              theme: { type: 'string', enum: ['auto', 'light', 'dark'] },
              layout: { type: 'string', enum: ['grid', 'list'] },
              showFooter: { type: 'boolean' },
            },
          },
        },
        required: ['config'],
      },
    },
  • src/index.ts:265-278 (registration)
    Dispatch handler in CallToolRequestSchema switch statement that invokes the updateConfig function.
    case 'update_config': {
      const { config } = args as { config: Record<string, unknown> };
      log.info('Executing update_config', { config });
      const result = await updateConfig(config);
      log.info('update_config completed', { result });
      return {
        content: [
          {
            type: 'text',
            text: JSON.stringify(result, null, 2),
          },
        ],
      };
    }
  • Type definition for the output/result of the updateConfig function.
    export interface UpdateConfigResult {
      success: boolean;
      config: ToyboxConfig;
      message?: string;
      error?: string;
    }
  • ArtifactService method called by the handler to persist config updates to TOYBOX_CONFIG.json file.
    async updateConfig(config: Partial<ToyboxConfig>): Promise<void> {
      const configPath = path.join(this.repoPath, 'TOYBOX_CONFIG.json');
      
      let existingConfig: ToyboxConfig = {
        title: 'My TOYBOX',
        description: 'A collection of my creative artifacts',
        theme: 'auto',
        layout: 'grid',
        showFooter: true,
      };
      
      // Read existing config if it exists
      if (await fs.pathExists(configPath)) {
        try {
          const configContent = await readFile(configPath, 'utf8');
          existingConfig = { ...existingConfig, ...JSON.parse(configContent) };
        } catch (error) {
          log.warn('Failed to read existing config, using defaults');
        }
      }
      
      // Merge with new config
      const updatedConfig = { ...existingConfig, ...config };
      
      // Write updated config
      await writeFile(configPath, JSON.stringify(updatedConfig, null, 2), 'utf8');
    }
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 states this is an update operation, implying mutation, but doesn't cover critical aspects like required permissions, whether changes are reversible, side effects, rate limits, or what the response looks like. This is a significant gap for a mutation tool.

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 waste. It's front-loaded with the core purpose and includes examples of updatable fields, making it easy to parse quickly.

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 mutation tool with no annotations, no output schema, and low schema description coverage (0%), the description is incomplete. It lacks details on behavioral traits, error handling, and response format, leaving the agent with insufficient context to use the tool effectively.

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?

The description mentions specific updatable fields ('title, theme, layout, etc.'), which adds meaning beyond the schema's property names. However, with 0% schema description coverage, it doesn't fully compensate by explaining the 'config' object structure, enum values, or optional vs. required fields. The baseline is 3 due to some added context.

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 ('Update') and resource ('TOYBOX configuration'), and specifies the scope of what can be updated ('title, theme, layout, etc.'). It doesn't explicitly differentiate from sibling tools, but the specificity of 'configuration' distinguishes it from tools like 'list_artifacts' or 'publish_artifact'.

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., whether the TOYBOX must be initialized first), exclusions, or recommend other tools for related tasks. The context is implied but not explicit.

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/isnbh0/toybox-mcp-server'

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