Skip to main content
Glama

config

Idempotent

Manage configuration settings for the OSS Autopilot server to customize its open-source contribution tracking and automation behavior.

Instructions

Get or set OSS Autopilot configuration values. With no args, shows all config. With key and value, sets the value.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoConfiguration key to get or set (e.g. "languages", "username")
valueNoValue to set for the given key. Omit to read the current value.

Implementation Reference

  • The implementation of the `config` command which handles getting and setting various configuration options like username, languages, labels, scopes, and repository/org exclusions.
    export async function runConfig(options: ConfigOptions): Promise<ConfigCommandOutput> {
      const stateManager = getStateManager();
      const currentConfig = stateManager.getState().config;
    
      if (!options.key) {
        // Show current config
        return { config: currentConfig };
      }
    
      if (!options.value) {
        throw new Error('Value required');
      }
      const value = options.value;
    
      // Handle specific config keys
      switch (options.key) {
        case 'username':
          stateManager.updateConfig({ githubUsername: validateGitHubUsername(value) });
          break;
        case 'add-language':
          if (!currentConfig.languages.includes(value)) {
            stateManager.updateConfig({ languages: [...currentConfig.languages, value] });
          }
          break;
        case 'add-label':
          if (!currentConfig.labels.includes(value)) {
            stateManager.updateConfig({ labels: [...currentConfig.labels, value] });
          }
          break;
        case 'remove-label':
          if (!currentConfig.labels.includes(value)) {
            throw new Error(
              `Label "${value}" is not currently configured. Current labels: ${currentConfig.labels.join(', ')}`,
            );
          }
          stateManager.updateConfig({ labels: currentConfig.labels.filter((l) => l !== value) });
          break;
        case 'add-scope': {
          const scope = validateScope(value);
          const currentScopes = currentConfig.scope ?? [];
          if (!currentScopes.includes(scope)) {
            stateManager.updateConfig({ scope: [...currentScopes, scope] });
          }
          break;
        }
        case 'remove-scope': {
          const scope = validateScope(value);
          const existingScopes = currentConfig.scope ?? [];
          if (!existingScopes.includes(scope)) {
            throw new Error(`Scope "${value}" is not currently set`);
          }
          const filtered = existingScopes.filter((s) => s !== scope);
          if (filtered.length === 0) {
            throw new Error('Cannot remove the last scope. Use setup to clear scopes entirely.');
          }
          stateManager.updateConfig({ scope: filtered });
          break;
        }
        case 'exclude-repo': {
          const parts = value.split('/');
          if (parts.length !== 2 || !parts[0] || !parts[1]) {
            throw new Error(
              `Invalid repo format "${value}". Use "owner/repo" format. To exclude an entire org, use: config exclude-org ${value}`,
            );
          }
          const valueLower = value.toLowerCase();
          if (!currentConfig.excludeRepos.some((r) => r.toLowerCase() === valueLower)) {
            stateManager.batch(() => {
              stateManager.updateConfig({ excludeRepos: [...currentConfig.excludeRepos, value] });
              stateManager.cleanupExcludedData([value], []);
            });
          }
          break;
        }
        case 'exclude-org': {
          if (value.includes('/')) {
            throw new Error(
              `Invalid org name "${value}". Use just the org name (e.g., "facebook"), not "owner/repo" format. To exclude a specific repo, use: config exclude-repo ${value}`,
            );
          }
          const currentOrgs = currentConfig.excludeOrgs ?? [];
          if (!currentOrgs.some((o) => o.toLowerCase() === value.toLowerCase())) {
            stateManager.batch(() => {
              stateManager.updateConfig({ excludeOrgs: [...currentOrgs, value] });
              stateManager.cleanupExcludedData([], [value]);
            });
          }
          break;
        }
        case 'issueListPath':
          stateManager.updateConfig({ issueListPath: value || undefined });
          break;
        case 'scoreThreshold': {
          const threshold = Number(value);
          if (!Number.isInteger(threshold) || threshold < 1 || threshold > 10) {
            throw new ValidationError(`Invalid value for scoreThreshold: "${value}". Must be an integer between 1 and 10.`);
          }
          stateManager.updateConfig({ scoreThreshold: threshold });
          break;
        }
        default:
          throw new Error(`Unknown config key: ${options.key}`);
      }
    
      return { success: true, key: options.key, value };
    }
  • Registration of the 'config' tool in the MCP server, mapping it to the `runConfig` function.
    // 11. config — Get or set configuration
    server.registerTool(
      'config',
      {
        description:
          'Get or set OSS Autopilot configuration values. With no args, shows all config. With key and value, sets the value.',
        inputSchema: {
          key: z.string().optional().describe('Configuration key to get or set (e.g. "languages", "username")'),
          value: z.string().optional().describe('Value to set for the given key. Omit to read the current value.'),
        },
        annotations: { readOnlyHint: false, idempotentHint: true },
      },
      wrapTool(runConfig),
    );
Behavior3/5

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

Consistent with annotations (acknowledges 'set' operation aligning with readOnlyHint:false). Adds valuable conditional behavior (no-args mode) but omits disclosure of return format, validation errors, or side effects beyond the basic get/set mechanics.

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?

Two efficient sentences with zero waste. Purpose is front-loaded, followed by specific conditional usage patterns. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Well-suited to the tool's simplicity with full schema coverage and annotations present. Appropriately explains the dual invocation modes, though could optionally hint at output structure for absolute completeness.

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

Parameters4/5

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

Despite 100% schema coverage, adds critical behavioral context that omitting both parameters displays all configuration—a key usage pattern not inferable from the schema alone which only describes the two optional fields.

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

Purpose5/5

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

Clearly states specific verbs (get/set) and resource (OSS Autopilot configuration values). Effectively distinguishes from setup/init siblings by focusing on ongoing configuration management versus initial setup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear internal usage patterns (no args shows all; key+value sets), but lacks explicit guidance on when to use this versus sibling alternatives like setup or check-setup.

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/costajohnt/oss-autopilot'

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