Skip to main content
Glama
Ripnrip

Quake Coding Arena MCP

by Ripnrip

get_voice_pack_info

Read-onlyIdempotent

Retrieve details about active and available voice packs for coding achievement announcements, including names, descriptions, and paths.

Instructions

â„šī¸ Get information about the currently active voice pack and all available voice packs. Returns the current voice pack name, display name, description, path, and list of all available voice packs (male and female) with their details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_dummyNoNo parameters required. This tool returns information about voice packs without requiring any input.

Implementation Reference

  • The core handler function for the 'get_voice_pack_info' tool. It returns success status, message, current voice pack, current voice info, and list of all available voice packs.
    async getVoicePackInfo(args) {
      return {
        success: true,
        message: "🎤 Voice pack information retrieved!",
        currentVoicePack: enhancedStats.voicePack,
        currentVoiceInfo: VOICE_PACKS[enhancedStats.voicePack],
        availableVoicePacks: Object.keys(VOICE_PACKS).map(key => ({
          id: key,
          ...VOICE_PACKS[key]
        }))
      };
    }
  • index.js:389-396 (registration)
    Registration of the 'get_voice_pack_info' tool in the ListTools response, including name, description, and input schema.
    {
      name: "get_voice_pack_info",
      description: "🎤 Get current voice pack information and available options",
      inputSchema: {
        type: "object",
        properties: {},
      },
    },
  • Input schema definition for the tool: an empty object since no parameters are required.
    inputSchema: {
      type: "object",
      properties: {},
    },
  • Alternative handler implementation in the modular tools registration file, returning structured content with voice pack information.
        async () => {
            return {
                content: [{
                    type: "text",
                    text: `🎤 Current voice: ${enhancedStats.voicePack}\nAvailable voices: male, female`
                }],
                currentVoicePack: enhancedStats.voicePack,
                currentVoiceInfo: VOICE_PACKS[enhancedStats.voicePack],
                availableVoicePacks: Object.entries(VOICE_PACKS).map(([id, pack]) => ({
                    id,
                    ...pack
                }))
            };
        }
    );
  • Registration of the tool using server.registerTool in the settings module, including detailed description, Zod schema, and annotations.
    server.registerTool(
        "get_voice_pack_info",
        {
            description: "â„šī¸ Get information about the currently active voice pack and all available voice packs. Returns the current voice pack name, display name, description, path, and list of all available voice packs (male and female) with their details.",
            inputSchema: {
                // No parameters required for this tool
                _dummy: z.string().optional().describe("No parameters required. This tool returns information about voice packs without requiring any input.")
            },
            annotations: {
                title: "â„šī¸ Get Voice Pack Info",
                readOnlyHint: true,
                destructiveHint: false,
                idempotentHint: true,
                openWorldHint: false
            }
        },
Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying the return content (current voice pack details and list of all available packs), which isn't covered by annotations, providing useful behavioral context beyond the structured hints.

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, well-structured sentence that efficiently conveys the tool's purpose and return value. It uses an emoji for visual emphasis and avoids redundancy, making it front-loaded and appropriately sized with no wasted words.

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?

Given the tool's low complexity (no real parameters, read-only operation) and rich annotations, the description is mostly complete. It specifies what information is returned, compensating for the lack of an output schema. However, it could briefly mention the tool's idempotent or safe nature, though annotations cover this, leaving a minor gap.

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?

With 100% schema description coverage, the schema fully documents the single dummy parameter. The description adds no parameter-specific information, but since there are effectively 0 functional parameters (the dummy parameter is a placeholder), this is acceptable. The baseline for high schema coverage is 3, but the lack of real parameters elevates the score to 4.

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?

The description clearly states the verb ('Get information') and resource ('about the currently active voice pack and all available voice packs'), distinguishing it from sibling tools like 'set_voice_pack' or 'test_voice_packs'. It specifies the scope of information returned, making the purpose explicit and differentiated.

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?

The description implies usage context by stating it returns information about 'currently active' and 'all available' voice packs, suggesting it's for querying voice pack details. However, it doesn't explicitly state when to use this tool versus alternatives like 'set_voice_pack' or 'test_voice_packs', nor does it provide exclusions or prerequisites.

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/Ripnrip/Quake-Coding-Arena-MCP'

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