Skip to main content
Glama

Handy Optimized Prompts

A local MCP app for building a user-approved transcript corpus from Handy, evaluating post-processing prompts against LM Studio, and promoting winning inference settings.

IMPORTANT

This repository is shared as an example for inspiration and adaptation. It reflects a personal local workflow and is not a production-ready package, supported product, or drop-in solution. Review and adapt its security, privacy, data-handling, and operational assumptions before using it.

Safety and data boundaries

  • Handy's history.db and settings_store.json are read-only.

  • Only transcription_history.transcription_text is imported. Historical Handy post-processing output is ignored.

  • Proposals, approved targets, dataset splits, prompts, and evaluation results live in this project's SQLite database.

  • Holdout examples are sealed after dataset creation. Optimization tools expose development examples and development failures only.

  • LM Studio settings are changed only by the promotion tool after a form confirmation. The existing per-model configuration is backed up first.

  • The project never downloads LM Studio models.

Related MCP server: Open Router Audio Transcription MCP

Requirements

  • macOS

  • Handy 0.9.0 or newer

  • LM Studio 0.4.0 or newer

  • Node.js 24 or newer

Default paths:

  • Handy history: ~/Library/Application Support/com.pais.handy/history.db

  • Prompt-lab data: ./data/handy-prompts.sqlite

  • LM Studio: ~/.lmstudio

  • LM Studio API: http://127.0.0.1:1234

Override them with HANDY_HISTORY_DB, HANDY_PROMPTS_DB, LM_STUDIO_HOME, or LM_STUDIO_BASE_URL.

Install and verify

npm install
npm test
npm run smoke

The smoke test reads the live Handy history into a temporary database and deletes that database afterward.

Connect to Codex Desktop over STDIO

The MCP server communicates through stdin and stdout only. It does not open an HTTP listener.

[mcp_servers.handy_prompt_lab]
command = "node"
args = ["/absolute/path/to/handy-optimized-prompts/src/server.js", "--stdio"]
startup_timeout_sec = 20
tool_timeout_sec = 1800

Restart Codex after changing the server code or configuration.

Annotation workflow

Start a Codex task and say:

Let's update Handy annotations.

Codex should:

  1. Call sync_handy_history.

  2. Call list_transcripts_needing_proposals with a maximum of 20.

  3. Generate conservative corrections and call save_correction_proposals.

  4. Call show_annotation_lab.

The widget saves each user decision through save_annotation_and_next and loads the next proposal directly. It does not use ui/message or ui/update-model-context.

End the task after annotation. Do not optimize the prompt in the same task, because that task has seen the prospective holdout transcripts.

Optimization workflow

Start a fresh Codex task and say:

Optimize my Handy prompt using the approved annotations.

Codex should:

  1. Call prepare_optimization_dataset with the required fresh-task confirmation.

  2. Inspect get_development_examples.

  3. Call list_lm_studio_models.

  4. Create a prompt/model/settings candidate with create_prompt_candidate.

  5. Call run_development_eval.

  6. Inspect detailed development failures with get_development_failures.

  7. Iterate until the development candidate is satisfactory.

  8. Freeze it with freeze_prompt_candidate.

  9. Call run_holdout_eval once. This returns aggregate metrics only.

The initial dataset uses a chronological split: the newest 20% are holdout. With fewer than five approved records, one record is held out when possible. Newly collected transcripts should supply rolling holdouts in later cycles.

Evaluation behavior

Candidates version:

  • Handy prompt-template text containing the literal ${output} placeholder

  • LM Studio model key

  • Temperature

  • Maximum output tokens

  • Optional top-p, top-k, min-p, and repeat penalty

For every evaluation record, the evaluator replaces ${output} with the raw transcript and sends the complete rendered prompt as a single user message. Candidates without ${output} are rejected. This matches Handy's legacy path for custom providers that do not advertise structured-output support.

Evaluation requests match Handy 0.9.0's custom-provider behavior by sending top-level reasoning_effort: "none". This is fixed rather than a candidate setting because Handy does not expose it. Model-specific thinking toggles in LM Studio remain unchanged during promotion.

The primary quality metric is normalized exact match. Normalization performs Unicode NFC cleanup, line-ending normalization, non-breaking-space conversion, outer trimming, and repeated horizontal-whitespace collapse. It preserves capitalization, punctuation, quote and dash style, numbers, words, word order, and line breaks.

The evaluator runs models sequentially. It records the initially loaded LM Studio models, loads the candidate model if necessary, and restores the originally loaded models after the run.

Promotion

plan_lm_studio_promotion shows the proposed per-model default changes.

promote_candidate_to_lm_studio requires:

  • A frozen candidate

  • A completed holdout evaluation

  • An accepted form confirmation

Promotion updates inference fields in:

~/.lmstudio/.internal/user-concrete-model-default-config/<model-key>.json

It preserves unrelated fields such as model-specific thinking toggles and creates a timestamped backup. Reload the model after promotion. The tool returns the winning prompt for manual entry in Handy; it does not write Handy settings.

References

License

This example is shared under the Common Grace License 1.0.

Available Tools

19 tools
annotation_summarySummarize annotation progressA
Read-only

Returns counts for imported, proposed, approved, edited, and skipped transcripts.

Inputs: no named parameters.

begin_annotation_cycleBegin a new annotation cycleA

Unlocks annotation access for newly collected Handy transcripts after explicit confirmation. Use from a fresh annotation task.

Inputs: no named parameters.

capability_reportReport MCP client capabilitiesB
Read-only

Reports client information and capabilities advertised to this MCP server.

Inputs: no named parameters.

create_prompt_candidateCreate a versioned prompt candidateB

Stores an immutable Handy-compatible prompt template, model, and inference settings for evaluation. The prompt must contain ${output}.

Inputs: name (required), model (required), prompt (required), settings.

freeze_prompt_candidateFreeze prompt candidateC

Freezes a candidate before sealed holdout evaluation.

Inputs: candidateId (required).

get_development_examplesGet prompt-development examplesB
Read-only

Returns approved raw/target pairs from the development split. Holdout records are never returned.

Inputs: limit, offset, datasetId.

get_development_failuresGet failed development casesA
Read-only

Returns detailed failed examples for a development evaluation. Holdout evaluation details are never exposed.

Inputs: runId (required), limit.

list_lm_studio_modelsList local LM Studio modelsA
Read-only

Lists downloaded local models and loaded instances from LM Studio. It does not download or change models.

Inputs: no named parameters.

list_transcripts_needing_proposalsList transcripts needing Codex proposalsA
Read-only

Returns a bounded batch of raw transcripts. Generate a conservative corrected transcript for every record, then call save_correction_proposals.

Inputs: limit, cursor.

load_annotation_recordLoad annotation recordC
Read-only

Loads a record from the current annotation widget batch.

Inputs: index (required), batchId (required).

plan_lm_studio_promotionPlan LM Studio defaults updateA
Read-only

Shows the exact LM Studio per-model defaults file and fields that would be changed for a candidate. Makes no changes.

Inputs: candidateId (required).

prepare_optimization_datasetSeal an optimization datasetA

Creates a chronological development/holdout split and locks annotation access. Call only from a fresh Codex task that has not seen transcript proposals.

Inputs: freshTaskConfirmation (required), holdoutFraction.

promote_candidate_to_lm_studioPromote candidate settings to LM StudioA

After form confirmation, backs up and updates LM Studio's per-model defaults for a frozen candidate that completed holdout evaluation. Handy remains read-only.

Inputs: candidateId (required).

run_development_evalRun prompt candidate on development setA

Sequentially evaluates a candidate against development examples, recording exact-match and latency metrics. LM Studio's prior model state is restored afterward.

Inputs: candidateId (required), datasetId.

run_holdout_evalRun sealed holdout evaluationA

Evaluates a frozen candidate on the sealed holdout. Returns aggregate metrics only.

Inputs: candidateId (required), datasetId.

save_annotation_and_nextSave annotation and load nextB

Saves a user-reviewed transcript target, then returns the next record in the widget batch.

Inputs: status (required), batchId (required), recordId (required), correctedText (required), +1 more.

save_correction_proposalsSave Codex correction proposalsA

Stores Codex-generated proposals for later user review. Proposals do not enter the evaluation set until the user approves them.

Inputs: proposals (required), author.

show_annotation_labShow Handy annotation labC
Read-only

Opens a widget for editing and approving a batch of Codex transcript proposals.

Inputs: limit, recordIds.

sync_handy_historySync raw Handy transcript historyA

Reads Handy's local history database without modifying it and imports new raw transcripts into the prompt lab.

Inputs: no named parameters.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    B3.4/5.0

    Scored across 19 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose. Overlaps are minimal; descriptions effectively differentiate between similar operations like annotation workflow steps and evaluation functions.

    Naming Consistency4/5

    Most tools follow a consistent verb_noun pattern (e.g., get_development_failures, freeze_prompt_candidate). However, 'annotation_summary' and 'capability_report' are noun-only, creating minor inconsistency.

    Tool Count5/5

    19 tools appropriately cover the full prompt lab lifecycle: data import, annotation, candidate creation, evaluation, and deployment. The count feels well-scoped without being overwhelming or insufficient.

    Completeness4/5

    The toolset covers main workflows (sync, annotate, create, evaluate, promote). Minor gaps exist (no delete/update for candidates, no undo for promotion), but these are likely intentional and do not block core use.

    Related MCP Connectors

    Related MCP Servers