Skip to main content
Glama

m9k_config

View or update plugin configuration for the Melchizedek MCP server. Changes save to ~/.melchizedek/config.json and apply after restart.

Instructions

View or update plugin configuration. Changes are saved to ~/.melchizedek/config.json and take effect on next server restart. Without arguments, returns current config.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoConfig key to update (e.g. 'rerankerEnabled')
valueNoNew value (JSON-encoded: 'false', '15', '"node-llama-cpp"')

Implementation Reference

  • The handler for the m9k_config tool which handles viewing and updating plugin configurations.
    server.registerTool(
      'm9k_config',
      {
        description:
          'View or update plugin configuration. Changes are saved to ~/.melchizedek/config.json and take effect on next server restart. Without arguments, returns current config.',
        inputSchema: {
          key: z.string().optional().describe("Config key to update (e.g. 'rerankerEnabled')"),
          value: z
            .string()
            .optional()
            .describe("New value (JSON-encoded: 'false', '15', '\"node-llama-cpp\"')"),
        },
        annotations: {
          readOnlyHint: false,
          destructiveHint: false,
          idempotentHint: false,
          openWorldHint: false,
        },
      },
      async ({ key, value }) => {
        // Without args: return current config + ignored projects
        if (!key) {
          const ignoredProjects = getIgnoredProjects(ctx.db);
          return {
            content: [
              {
                type: 'text' as const,
                text: JSON.stringify({ ...ctx.cfg, ignoredProjects }),
              },
            ],
          };
        }
    
        // With key+value: update config
        if (!value) {
          throw new McpError(ErrorCode.InvalidParams, 'Both key and value are required for updates');
        }
    
        if (!CONFIGURABLE_KEYS.has(key)) {
          throw new McpError(
            ErrorCode.InvalidParams,
            `Unknown config key: ${key}. Valid keys: ${[...CONFIGURABLE_KEYS].join(', ')}`,
          );
        }
    
        let parsed: unknown;
        try {
          parsed = JSON.parse(value);
        } catch {
          throw new McpError(ErrorCode.InvalidParams, `Invalid JSON value: ${value}`);
        }
    
        writeConfigFile({ [key]: parsed } as Partial<MelchizedekConfig>);
    
        // Update in-memory config
        const updatedCfg = { ...ctx.cfg, [key]: parsed };
        Object.assign(ctx.cfg, updatedCfg);
    
        // Hot-reload reranker when relevant keys change
        let hotReloadFailed = false;
        if (RERANKER_HOT_RELOAD_KEYS.has(key)) {
          try {
            const detected = await detectRerankerBackend(ctx.cfg);
            if (detected) {
              ctx.searchContext.reranker = detected.reranker;
            } else {
              // New config doesn't yield a reranker — keep old one active
              hotReloadFailed = true;
            }
          } catch {
            hotReloadFailed = true;
          }
        }
    
        const restartRequired = RESTART_REQUIRED_KEYS.has(key);
    
        return {
          content: [
            {
              type: 'text' as const,
              text: JSON.stringify({
                updated: true,
                key,
                config: updatedCfg,
                hotReloadFailed,
                restartRequired,
              }),
            },
          ],
        };
      },
    );
Behavior5/5

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

Excellent disclosure beyond annotations: specifies persistence path ( ~/.melchizedek/config.json) and activation timing (next server restart). Accurately reflects readOnlyHint=false by acknowledging mutation capability without contradiction.

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?

Three tightly constructed sentences with zero waste: front-loaded purpose, followed by side effects, then usage variant. Every sentence carries distinct necessary information.

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?

Thoroughly covers dual-mode behavior, file persistence, and restart requirements for a state-modifying tool. Minor gap in not describing return value structure, though absence of output schema reduces obligation.

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 coverage is 100%, establishing baseline 3. Description adds context for optional usage via 'Without arguments' clause but does not expand on parameter syntax, validation rules, or encoding details beyond schema descriptions.

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?

Specific verbs ('View or update') and resource ('plugin configuration') with precise scope distinguished by specific file path (~/.melchizedek/config.json), clearly differentiating from sibling data tools like m9k_save or m9k_search.

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

Usage Guidelines4/5

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

Provides clear conditional usage via 'Without arguments, returns current config', implicitly defining the dual-mode operation (view vs update). Lacks explicit naming of sibling alternatives but conveys when to omit parameters.

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/louis49/melchizedek'

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