Skip to main content
Glama

Run calibration test

run_calibration_test

Run heuristic calibration prompts against a local AI model and store scores in ~/.msty-admin; returns JSON with tests_run and average_score.

Instructions

Run heuristic calibration prompts against a Local AI model and store scores in ~/.msty-admin. Use evaluate_response_quality to score a single reply without calling the model. Calls local inference and writes sidecar metrics. Returns JSON with tests_run and average_score.

Input Schema

NameRequiredDescriptionDefault
categoryNoPrompt category, or general for one prompt per category. Default general.general
model_idNoLocal AI model to test. Omit to use the first installed model.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv6.2.1
    • addedInput schema / properties / category / description
      Added value: +"Prompt category, or general for one prompt per category. Default general."
    • addedInput schema / properties / model_id / description
      Added value: +"Local AI model to test. Omit to use the first installed model."
  2. First observedv5.0.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description correctly doesn't need to restate safety. It adds real value beyond them: the tool invokes local inference (nontrivial compute) and writes sidecar metrics to a specific directory, which are not derivable from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action and side effect, with no filler. The final sentence restates return fields already covered by the output schema, a minor redundancy that keeps it off a 5.

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?

With annotations, a full-coverage schema, and an output schema present, the description covers the essentials: what runs, where results land, and which sibling to use instead. Only the practical cost/latency implications of triggering local inference are left implicit.

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%, so category and model_id are already fully documented, including the 'omit to use the first installed model' default behavior. The description adds no syntax, valid-range, or interplay detail beyond what the schema provides, so the baseline 3 applies.

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 gives a specific verb and resource ('Run heuristic calibration prompts against a Local AI model') plus the persistence side effect (~/.msty-admin). It also explicitly distinguishes itself from the sibling evaluate_response_quality, so an agent can route between them without opening a schema.

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?

It names the alternative tool and the condition that selects it ('to score a single reply without calling the model'), which is clear routing guidance. It stops short of stating when not to run this tool (cost, latency, prerequisites for a local model), so it falls just below the full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.