hugomemo-qa
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HUGOMEMO_QA_ENV | No | The QA environment name (e.g., development). | development |
| HUGOMEMO_API_URL | No | The base URL of the Hugomemo API server. | http://127.0.0.1:3000 |
| HUGOMEMO_QA_ACCESS_TOKEN | Yes | Access token for the Hugomemo QA API, injected via the MCP host environment. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| qa_healthA | Read-only Hugomemo API/database health. Does not require a user token. |
| qa_get_app_snapshotB | Fetch a bounded server-truth snapshot for Today, Progress, entitlement, usage, and account data. |
| qa_get_current_sessionA | Read the authenticated server session from Today, including validity and progress counters. |
| qa_get_current_roundB | Read the next server-selected queue round. This is not a claim about the active UI round. |
| qa_get_game_stateA | Read optional instrumented live game state; returns not_observable when no sidecar/bridge is configured. |
| qa_get_attemptsA | Read recent server-owned attempts from the complete account export; raw round details are retained. |
| qa_get_round_detailB | Find one exact server attempt by client_attempt_id, or return the most recent bounded attempt. |
| qa_get_skill_ratingsB | Read raw skill ratings, attempt counts, uncertainty, and the score conversion source. |
| qa_get_memory_scoreA | Read the server memory score without inventing zero; optionally compare a score observed in the UI. |
| qa_get_entitlementA | Read server-authoritative plan, status, billing product identity, and AI credits. |
| qa_get_usageA | Read the separate AI-credit, rewarded-insight, streak-freeze, and bounded AI activity ledgers. |
| qa_get_sync_statusC | Report server attempt/session evidence and clearly identify whether the local SQLite queue is observable. |
| qa_validate_app_contractA | Run bounded read-only contract checks against health and all authenticated application-truth endpoints. |
| qa_reset_test_userC | Reset a test user through the opt-in local fixture control plane. |
| qa_set_subscriptionA | Set a test subscription through the opt-in local fixture control plane. |
| qa_seed_questionsB | Seed test questions through the opt-in local fixture control plane. |
| qa_set_game_levelC | Set one test game level config through the opt-in local fixture control plane. |
| qa_force_offline_queueA | Toggle a test offline-queue fixture through the opt-in local fixture control plane. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 18 tools
Most tools have clearly distinct purposes, with the qa_get_* family splitting out entitlement, usage, session, round, attempts, ratings, and sync status. A few could cause mild confusion—get_app_snapshot overlaps with individual getters, and get_attempts vs get_round_detail both touch attempt data—but the descriptions provide enough separation.
All tools share a consistent qa_ prefix and use snake_case verb_object naming: qa_get_* for reads, qa_set_*/qa_reset_*/qa_seed_*/qa_force_* for fixture mutations, and qa_validate_* for contract checks. The pattern is uniform and predictable.
Eighteen tools is on the heavier side for a typical MCP server, but the count is justified by the QA instrumentation scope: many read-only truth endpoints plus a distinct fixture control-plane group. There is no obvious filler or redundancy that would make the set feel bloated.
The surface covers health, entitlement/usage, session/round/attempt data, skill/memory ratings, sync status, contract validation, and test-user fixtures. Minor gaps exist—such as no explicit create-test-user tool or read-back for seeded questions—but the core QA and test-fixture workflows are well supported.