Skip to main content
Glama

Quick LibreModel Test

quick_test

Verify LibreModel MCP Server connectivity by running diagnostic tests for response validation and system health checks.

Instructions

Run a quick test to see if LibreModel is responding

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
test_typeNoType of test to runhello

Implementation Reference

  • The handler function for the 'quick_test' tool. It selects a predefined prompt based on the test_type parameter, sends it to LibreModel via callLlamaServer, and returns the response with performance metrics or an error.
    }, async (args) => {
      const testPrompts = {
        hello: "Hello! Can you introduce yourself?",
        math: "What is 15 + 27?",
        creative: "Write a short haiku about artificial intelligence.",
        knowledge: "What is the capital of France?"
      };
    
      const testPrompt = testPrompts[args.test_type as keyof typeof testPrompts] || testPrompts.hello;
    
      try {
        const response = await this.callLlamaServer({
          message: testPrompt,
          temperature: 0.7,
          max_tokens: 256,
          top_p: 0.95,
          top_k: 40,
          system_prompt: ""
        });
    
        return {
          content: [
            {
              type: "text",
              text: `**${args.test_type} test result:**\n\n**Prompt:** ${testPrompt}\n\n**LibreModel Response:**\n${response.content}\n\n**Performance:**\n- Tokens generated: ${response.tokens_predicted}\n- Tokens evaluated: ${response.tokens_evaluated}\n- Success: ✅`
            }
          ]
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `**${args.test_type} test failed:**\n${error instanceof Error ? error.message : String(error)}`
            }
          ],
          isError: true
        };
      }
    });
  • The schema definition for the 'quick_test' tool, including title, description, and inputSchema with test_type enum.
    title: "Quick LibreModel Test",
    description: "Run a quick test to see if LibreModel is responding",
    inputSchema: {
      test_type: z.enum(["hello", "math", "creative", "knowledge"]).default("hello").describe("Type of test to run")
    }
  • src/index.ts:112-157 (registration)
    The registration of the 'quick_test' tool using server.registerTool, passing the schema and handler function.
    this.server.registerTool("quick_test", {
      title: "Quick LibreModel Test",
      description: "Run a quick test to see if LibreModel is responding",
      inputSchema: {
        test_type: z.enum(["hello", "math", "creative", "knowledge"]).default("hello").describe("Type of test to run")
      }
    }, async (args) => {
      const testPrompts = {
        hello: "Hello! Can you introduce yourself?",
        math: "What is 15 + 27?",
        creative: "Write a short haiku about artificial intelligence.",
        knowledge: "What is the capital of France?"
      };
    
      const testPrompt = testPrompts[args.test_type as keyof typeof testPrompts] || testPrompts.hello;
    
      try {
        const response = await this.callLlamaServer({
          message: testPrompt,
          temperature: 0.7,
          max_tokens: 256,
          top_p: 0.95,
          top_k: 40,
          system_prompt: ""
        });
    
        return {
          content: [
            {
              type: "text",
              text: `**${args.test_type} test result:**\n\n**Prompt:** ${testPrompt}\n\n**LibreModel Response:**\n${response.content}\n\n**Performance:**\n- Tokens generated: ${response.tokens_predicted}\n- Tokens evaluated: ${response.tokens_evaluated}\n- Success: ✅`
            }
          ]
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `**${args.test_type} test failed:**\n${error instanceof Error ? error.message : String(error)}`
            }
          ],
          isError: true
        };
      }
    });
Behavior2/5

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

With no annotations, the description carries full burden but only states it tests responsiveness. It doesn't disclose what 'responding' entails (e.g., latency expectations, success criteria), whether it's read-only or has side effects, or what happens with different test types. This leaves significant behavioral gaps for a tool with multiple test options.

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 immediately states the tool's purpose. Every word earns its place with no redundancy or unnecessary elaboration, making it appropriately sized and front-loaded.

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?

For a tool with no annotations, no output schema, and multiple test types, the description is insufficient. It doesn't explain what different test types do, what output to expect, or how to interpret results. The context signals show complexity (enum parameter) that isn't addressed, leaving the agent under-informed.

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%, with the parameter 'test_type' fully documented in the schema (enum values, default). The description adds no parameter-specific information beyond implying all types test responsiveness. Since the schema does the heavy lifting, the baseline 3 is appropriate despite the description's minimal contribution.

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 ('Run a quick test') and the target ('LibreModel'), specifying the purpose as checking responsiveness. It distinguishes from 'health_check' by focusing on functional testing rather than system status, but doesn't explicitly differentiate from 'chat' beyond the testing context.

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?

The description implies usage when needing to verify LibreModel's responsiveness, but provides no explicit guidance on when to choose this tool over 'health_check' or 'chat'. The 'quick' qualifier suggests it's for lightweight verification, but alternatives and exclusions aren't addressed.

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/openconstruct/llama-mcp-server'

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