Running Pack Wizard and Signal Agent from Claude, Not the Dashboard

Pack Wizard and Signal Agent — the two agents behind HuMetric's dashboard — have always lived in the browser. You open the Packs tab, click "New pack," answer a few questions, and an agent researches and drafts a Metric Pack for you. It works well, but it assumes you're sitting in the dashboard when the idea strikes. If you already live in Claude Code, Cursor, or another MCP-connected tool all day, that's a context switch you shouldn't need.

We just removed it. A new remote MCP server puts both agents one tool call away from wherever you already work.

This is not the other HuMetric MCP server

HuMetric already ships a local MCP server (mcp_server.py, described in these docs) that gives an LLM three read/write tools against your raw entities and signals: query, get, ingest. If you just want an assistant that can look up a metric or log a signal, that one is simpler — it's a single Python file you run locally against your engine API key.

This is a different, second server. It doesn't touch entities or signals directly — it opens the two agents themselves: the one that designs a Metric Pack from a description, and the one that turns pasted text into a signal-ingestion plan and runs it. Where the local server is a thin read/write proxy, this one is agentic — it researches, asks clarifying questions when it matters, and hands back a finished result.

BYOK: your key runs the agent, not ours

Neither of these agents runs on a HuMetric-operated model. Whichever LLM provider you've connected in the dashboard's BYOK panel — Anthropic, OpenAI, DeepSeek, or Google — is what actually does the reasoning, at your own provider's rates, billed directly to you by them.

On top of that, the Signal Agent has a persistent memory across sessions, kept on our own side — no extra key, no third-party service, on by default for every account. The agent writes down what's worth keeping via remember_context: your entity-id naming convention, a recurring quirk in a source you paste from, how you want an unfillable field handled. The next session reads those before its first turn, so you don't re-explain them.

This is also why the MCP server needs a key of its own, separate from your BYOK provider keys: an hms_live_... token, minted from the dashboard's new MCP panel, that identifies you to this server — not to any LLM.

Pricing: a flat fee, not a metered one

Because BYOK means your own provider bill covers the actual LLM cost, this server's fee has nothing to do with tokens. It's a flat, per-action platform charge, deducted from a separate MCP credit balance:

Checking in on a session costs nothing — only the turns that actually make the agent do work are billed.

Connecting it

1. Add a BYOK key. Dashboard → provider keys. Without one, every tool call fails immediately with llm_key_required — nothing is charged for that failure.

2. Mint an MCP key. Dashboard's new MCP panel, "New key." The token is shown once.

3. Add it to your client. For Claude Code:

   claude mcp add --transport http humetric-site https://gethumetric.com/mcp \
     --header "Authorization: Bearer hms_live_your_key_here"
   

   Cursor and any other MCP client that supports remote HTTP servers use the same URL and the same Authorization: Bearer header — see the full connection guide for exact config snippets.

Designing a pack without leaving the terminal

Once connected, humetric_pack_wizard_start takes the same inputs the dashboard form does — free text, an optional DB schema, sample data — and returns a session_id immediately; the agent keeps working after the call returns.

humetric_pack_wizard_start(text: "Score call-center agent quality from call
  transcripts: politeness, resolution speed, and whether the issue was
  actually resolved.")
→ { session_id: "..." }

humetric_pack_wizard_status(session_id: "...")
→ { status: "awaiting_input", pending_question: { question: "..." } }

humetric_pack_wizard_answer(session_id: "...", answer: "...")
→ { status: "completed", result: { pack_yaml: "entity_type: call...\n..." } }

From there, the engine's own MCP tool publishes it directly — humetric_create_pack(pack_yaml) — no copy-pasting between two chat windows.

Turning pasted text into real metrics

humetric_signal_chat_start is the same agent behind the dashboard's "Try it" panel, but callable against an existing pack without opening it. Paste a batch of reviews, transcripts, or ticket text against a pack_key, and the agent drafts an ingestion plan: which entity, which pieces of text become which signals, what to do about a field it can't fill.

humetric_signal_chat_start(pack_key: "call-center-quality", text: "<pasted
  transcripts>")
→ { session_id: "..." }

humetric_signal_chat_status(session_id: "...")
→ { status: "awaiting_input", result: { plan: { entity: {...}, signals: [...] } } }

Not happy with the plan? humetric_signal_chat_answer sends feedback and the agent redrafts it. Once it looks right, humetric_signal_chat_run_plan actually applies it — upserts the entity, submits every signal, waits for extraction, and returns the real metric values the engine computed. That last step is the only one that touches live data; everything before it is just planning.

The two agents you already knew from the dashboard, now reachable from wherever you actually write code.