Skip to main content
Glama
burkeholland

VS Code MCP Button Generator

by burkeholland

Buttons from MCP config

from_mcp_config

Generate VS Code installation buttons and badges from MCP configuration objects to simplify server setup.

Instructions

Generate install buttons from a raw MCP JSON-like config object and a server name.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesServer display name.
mcpNo

Implementation Reference

  • The handler function for the 'from_mcp_config' tool. It extracts inputs and config from the provided MCP object using the helper function, generates the install buttons markdown, and returns it as structured content.
    async ({ name, mcp }) => {
      const { inputs, config } = fromMcpConfigObject(name, mcp ?? {});
      const markdown = generateButtonsMarkdown(name, inputs, config);
      return { content: [{ type: "text", text: markdown }] };
    }
  • src/index.ts:132-147 (registration)
    Registration of the 'from_mcp_config' tool on the MCP server using server.registerTool.
    server.registerTool(
      "from_mcp_config",
      {
        title: "Buttons from MCP config",
        description: "Generate install buttons from a raw MCP JSON-like config object and a server name.",
        inputSchema: {
          name: z.string().describe("Server display name."),
          mcp: z.any(),
        }
      },
      async ({ name, mcp }) => {
        const { inputs, config } = fromMcpConfigObject(name, mcp ?? {});
        const markdown = generateButtonsMarkdown(name, inputs, config);
        return { content: [{ type: "text", text: markdown }] };
      }
    );
  • Input schema definition for the 'from_mcp_config' tool using Zod, specifying 'name' as string and 'mcp' as any.
    inputSchema: {
      name: z.string().describe("Server display name."),
      mcp: z.any(),
    }
  • Helper function used by the handler to parse the MCP config object into inputs (MCPInput[]) and config (CommandConfig).
    export function fromMcpConfigObject(name: string, configObj: any): { inputs: MCPInput[]; config: CommandConfig } {
      // Accepts a JSON like the example and converts env placeholders ${input:...} to VS Code expected rendering untouched.
      const inputs = Array.isArray(configObj.inputs) ? (configObj.inputs as MCPInput[]) : [];
    
      // For NPX-based servers, we expect the consumer to specify the npx invocation
      // Example: { command: 'npx', args: ['-y', '@scope/server@latest', '--flag'], env: { KEY: '${input:id}' } }
      // If not given, default to npx with no args
      const config: CommandConfig = configObj.config ?? { command: 'npx', args: [] };
      return { inputs, config };
    }
  • Type definitions for MCPInput and CommandConfig used in the tool's inputs and config parsing.
    export type MCPInput = {
      type: string;
      id: string;
      description?: string;
      password?: boolean;
    };
    
    export type CommandConfig = {
      command: string; // e.g., "npx"
      args?: string[];
      env?: Record<string, string>;
    };
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 generates something ('install buttons'), implying a creation or transformation operation, but doesn't specify what the output looks like, whether it's idempotent, if there are side effects, or any performance considerations. The description is too vague to provide meaningful behavioral insights beyond the basic action.

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 function and inputs without unnecessary words. It's front-loaded with the core action and avoids redundancy, making it easy to parse quickly. Every part of the sentence contributes essential information, earning its place.

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?

Given the tool has 2 parameters with only 50% schema coverage, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain the output format (what 'install buttons' are), lacks behavioral details, and provides minimal parameter guidance. For a tool that generates something from config data, more context is needed to ensure correct usage by an agent.

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 50% (only 'name' has a description), and the description adds minimal value beyond the schema. It mentions 'raw MCP JSON-like config object' for the 'mcp' parameter, which hints at its type but doesn't clarify format, structure, or constraints. Since schema coverage is moderate, the description partially compensates but leaves key details undocumented, aligning with the baseline for this coverage level.

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 ('Generate install buttons') and the inputs ('from a raw MCP JSON-like config object and a server name'), making the purpose understandable. It distinguishes itself by specifying the source as 'MCP config', which differentiates it from sibling tools like 'copilot_buttons_from_github' or 'copilot_buttons_from_raw'. However, it doesn't fully specify what 'install buttons' are or their format, leaving some ambiguity.

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 mentions the inputs but doesn't explain scenarios where this is preferred over sibling tools like 'make_install_buttons' or 'copilot_buttons_from_raw'. There's no mention of prerequisites, constraints, or typical use cases, leaving the agent without contextual usage cues.

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/burkeholland/mcp-vsc-button-gen'

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