Skip to main content
Glama

configure_openrouter_token

Set up your OpenRouter API key to enable image generation and editing capabilities using the Gemini 2.5 Flash Image model.

Instructions

Configure your OpenRouter API token for image generation

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
apiKeyYesYour OpenRouter API key from https://openrouter.ai/settings/keys

Implementation Reference

  • The primary handler function that extracts the API key from the tool request, validates it using ConfigSchema, sets up the OpenAI client configured for OpenRouter, updates the config source, saves the configuration to a file, and returns a success response with text content.
    private async configureOpenRouterToken(request: CallToolRequest): Promise<CallToolResult> {
      const { apiKey } = request.params.arguments as { apiKey: string };
      
      try {
        ConfigSchema.parse({ openrouterApiKey: apiKey });
        
        this.config = { openrouterApiKey: apiKey };
        this.openai = new OpenAI({
          apiKey,
          baseURL: "https://openrouter.ai/api/v1",
        });
        this.configSource = 'config_file'; // Manual configuration via tool
        
        await this.saveConfig();
        
        return {
          content: [
            {
              type: "text",
              text: "✅ OpenRouter API token configured successfully! You can now use OpenRouter image generation features.",
            },
          ],
        };
      } catch (error) {
        if (error instanceof z.ZodError) {
          throw new McpError(ErrorCode.InvalidParams, `Invalid API key: ${error.errors[0]?.message}`);
        }
        throw error;
      }
    }
  • src/index.ts:64-77 (registration)
    Tool registration in the listTools response, defining the name, description, and input schema requiring an 'apiKey' string.
    {
      name: "configure_openrouter_token",
      description: "Configure your OpenRouter API token for image generation",
      inputSchema: {
        type: "object",
        properties: {
          apiKey: {
            type: "string",
            description: "Your OpenRouter API key from https://openrouter.ai/settings/keys",
          },
        },
        required: ["apiKey"],
      },
    },
  • Zod schema for validating the OpenRouter API key, used internally in the handler for additional validation.
    const ConfigSchema = z.object({
      openrouterApiKey: z.string().min(1, "OpenRouter API key is required"),
    });
  • src/index.ts:178-180 (registration)
    Switch case in the CallToolRequest handler that dispatches to the configureOpenRouterToken method.
    case "configure_openrouter_token":
      return await this.configureOpenRouterToken(request);
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool configures an API token but doesn't describe what this entails—whether it stores the token persistently, requires specific permissions, has side effects (e.g., overwriting existing configuration), or what happens on success/failure. For a configuration tool with zero annotation coverage, this leaves critical behavioral traits unclear.

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 is front-loaded and appropriately sized for a simple configuration tool, with zero waste or redundancy.

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

Completeness3/5

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

Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on behavioral aspects like persistence or error handling. Without annotations or output schema, more context on what 'configure' entails would improve completeness, but it's not entirely inadequate for this simple case.

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%, with the parameter 'apiKey' fully documented in the schema (including a URL for obtaining the key). The description adds no additional meaning beyond what the schema provides, as it doesn't elaborate on parameter usage, format, or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but doesn't need to heavily.

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 ('configure') and the resource ('OpenRouter API token for image generation'), making the purpose understandable. It doesn't explicitly distinguish from sibling tools like 'get_configuration_status' or 'generate_image', but the verb 'configure' implies a setup action rather than retrieval or usage, providing some implicit differentiation.

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., needing an API key first), when it should be invoked (e.g., before generating images), or how it relates to sibling tools like 'get_configuration_status' for checking configuration. Usage is implied only by the action 'configure', with no explicit context.

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/WeiYu021/openrouter-image-MCP'

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