Skip to main content
Glama

remix_hook

Archived source-free remix writer. Use research_hook_evidence instead. Always fails before rewriting, model, storage, or billing work. An extracted source hook cannot be replaced by generated or paraphrased copy. Errors: unauthorized; invalid_request with reason unsourced_hook_generation_archived.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tagsNo1-5 lowercase slug tags ([a-z0-9_-], <=40 chars) stamped on this call's usage event so a fleet can attribute spend per campaign. Omit for no tagging. Filter later with get_usage(tag=...) / list_hooks(tag=...).
textNoThe existing hook to rewrite, 3-300 chars. Its subject is kept; only the angle moves to target_archetype. Pass this OR `hook_id`, never both and never neither.
countNoArchived compatibility count, 1-5. Remix fails before work or customer charge.
topicNoThe subject the hook was written FOR, scored as on score_hook: the verbatim-echo penalty only fires when the scorer is told the topic, so a hook (or a variant) that repeats its own subject scores up to 8 points higher without it and the rank order of the pack can differ. Only needed with `text`: a remix by `hook_id` reads the topic off the hook you bought. Sending both is fine when they are equal and a disagreement is a typed invalid_request rather than a silent winner. Omit for unchanged behaviour.
api_keyNoAPI key for this call. Omit to fall back to the Authorization: Bearer / X-API-Key request header (streamable-HTTP only), then the VHGENGINE_API_KEY env var (the stdio default). No key resolvable -> unauthorized.
hook_idNoRemix a hook you ALREADY bought, by the id a generate/batch/remix response returned (also listed by list_hooks): the stored text is looked up for you, so you do not have to carry it back. Account-scoped, so an unknown or foreign id is the same not_found get_hook returns. Pass this OR `text`, never both and never neither.
platformNoThe platform whose SCORING WINDOW grades these variants, as on generate_hooks and score_hook: LinkedIn's ideal hook length is 10-18 words against 8-14 elsewhere, so it moves both score.total and the rank order. Each variant's total is then reproducible through score_hook with the SAME platform, and the scale used is echoed back as `platform`. Omit for tiktok (unchanged behaviour).
archetypeNoAlias for `target_archetype`, spelled the way every hook object in every response spells it. Send either one; sending both is fine only if they are equal, and a disagreement is a typed invalid_request rather than a silent winner.
verbosityNoHow much of the response envelope to return: minimal (identity, text, score total/source, money, honesty warnings, and any persona/shape), standard (the default, including hook receipts), full (adds per-dimension score numbers, notes, and attribution). A failing phone_test survives minimal; passing phone_test, say_it, and pattern_source are standard/full detail. Shapes the RESPONSE only, never what is generated, persisted, hashed for idempotency, or charged.standard
idempotency_keyNoCaller-chosen replay key (any string, unique per intended effect). A repeat call with the SAME key returns the stored result and is NEVER charged twice; the same key with different arguments is an idempotency_conflict. Omit and every call is a fresh, separately charged operation.
target_archetypeNoArchetype id to rewrite INTO (see list_archetypes for ids and their psychology). `archetype` is an accepted alias for this argument; one of the two is required, there is no default angle.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoWhy these rewrites fit the target archetype, or null.
remixesNoThe variants: {id, text, archetype, score, rank}. Billed per variant RETURNED, so this can be shorter than count.
originalNo{text, score} of what you passed in.
platformNoThe platform scoring window every total above was produced on. Score a variant through score_hook with this SAME platform to reproduce its number; a different window gives a different total and a different rank. null when the request named none, which means the tiktok default.
replayedNotrue when an idempotency_key replayed a stored result, so nothing was charged again. The credits_charged below is what the ORIGINAL call cost.
request_idNoId of this call. Keep it: get_usage(request_id=...) itemises exactly what it charged, and it identifies the call in a support question.
topic_coreNoThe subject the remixer preserved from the original.
llm_fallbackNotrue when the LLM remixer was unavailable and the deterministic one ran; llm_fallback_reason says why. You are billed for what RAN.
remix_engineNoWhich remixer produced the variants.
credits_chargedNoCredits this call actually cost.
score_disclaimerNoThe honest limits of the score attached above.
credits_remainingNoYour balance AFTER this charge.
replayed_at_chargeNotrue when the replay was detected at the charge boundary rather than up front; either way you are billed exactly once.
llm_fallback_reasonNoWhy the fallback happened, or null.

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and discloses that the tool always fails before any work, never charges, and returns specific errors ('unauthorized; invalid_request with reason unsourced_hook_generation_archived'). This is fully transparent regarding the tool's guaranteed failure.

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?

Four short sentences front-load the core facts (archived, fail, alternative) and then list the error conditions. Every sentence serves a purpose with zero wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that the tool always fails, the description fully covers behavior, errors, and the recommended replacement. The output schema exists, so return-value details are unnecessary. The context is complete for any agent evaluating this tool.

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?

The input schema already provides exhaustive descriptions for all 11 parameters (100% coverage), so the tool description does not need to add parameter-level detail. The description adds no parameter-specific semantics, but the schema fully compensates, so the baseline of 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 immediately establishes the tool as an 'Archived source-free remix writer' and states it 'Always fails before rewriting, model, storage, or billing work.' This clearly signals it is a deprecated, non-functional tool and differentiates it from the recommended research_hook_evidence alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs the agent to 'Use research_hook_evidence instead' and notes the tool 'Always fails,' making it unambiguous that this tool should never be invoked. The alternative is named, and the failure behavior is stated up front.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool targets a distinct resource and action, e.g., signup vs. delete_account, create_key vs. revoke_key, generate_hooks vs. score_hook. Even similar tools like generate_hooks and generate_hooks_batch are clearly differentiated by single vs. batch operation.

Naming Consistency5/5

All 32 tools use a consistent verb_noun snake_case pattern (e.g., add_credits, create_checkout, revoke_key, list_outcomes) with no mixing of camelCase or other conventions.

Tool Count4/5

32 tools is slightly above the typical 15-tool range, but the domain is broad (account, keys, webhooks, generation, scoring, jobs, outcomes), and each tool has a specific purpose. No tools seem redundant.

Completeness4/5

The tool surface covers most lifecycle operations: CRUD for accounts/keys/webhooks, generation/scoring with batch and async variants, outcomes reporting, and auxiliary tools. Missing explicit delete for hooks (expire automatically) and some update operations, but no critical gaps.

Resources