Skip to main content
Glama

score_hook

Score any hook text on 5 dimensions with rewrite tips. Free during beta.

    Deterministic heuristic scorer (no LLM). Args: text (3-300), platform, topic
    (optional, reproduces generate's score via the verbatim-echo penalty), tags (1-5
    fleet slugs, WP-J), verbosity (full keeps per-dimension attribution), api_key,
    idempotency_key (replay not re-charged). Returns {score:{...,total}, verdict,
    suggestions, confidence, disclaimer, credits_charged, credits_remaining, request_id}.
    Errors: unauthorized, invalid_request, insufficient_credits, rate_limited.
    

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=...).
textYesThe hook line to score, 3-300 chars. Any text is accepted (it does not have to be one Hook Detector generated) and it is never persisted as a hook you own.
topicNoThe subject this text was written FOR. Pass the SAME topic string a generate call used and this reproduces the exact score.total that generate served for the hook: the scorer's verbatim-echo penalty only fires when it is told the topic, so a hook that repeats its own subject scores up to 8 points higher without it. Omit to score the text on its own (unchanged behaviour). Two caveats on exactness: a hook flagged contains_placeholder_stat was scored with a fabricated-number penalty this cannot apply, and a total capped at the deterministic template ceiling says so in score.notes at verbosity=full.
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.
platformNoTarget platform, which selects the length/format conventions the hooks are written and scored against. Defaults to tiktok when omitted.tiktok
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.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoreNoPer-dimension scores plus `total`.
verdictNoOne-line read of the total.
replayedNotrue when an idempotency_key replayed a stored result, so nothing was charged again. The credits_charged below is what the ORIGINAL call cost.
confidenceNoHow much weight to put on this score.
disclaimerNoThe honest limits of the scorer. Worth surfacing to your human.
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.
suggestionsNoConcrete rewrite tips.
credits_chargedNoCredits this call actually cost.
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.

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description discloses key traits: 'Deterministic heuristic scorer (no LLM)', 'Free during beta', error types, and billing behavior with idempotency key 'replay not re-charged'. This fully covers safety and side effects.

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?

The description is concise and well-structured with an opening purpose sentence followed by Args, Returns, and Errors sections. The cryptic 'WP-J' in the Args line slightly hurts clarity.

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 7 parameters and an output schema present, the description covers purpose, parameters, return envelope, errors, and pricing. It does not enumerate the 5 scoring dimensions, but that is likely in the output schema; overall it is sufficiently complete.

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 schema provides 100% coverage with detailed descriptions for all 7 parameters, so baseline is 3. The description's Args line summarizes parameters but adds little beyond the schema, e.g., verbosity 'full keeps per-dimension attribution' duplicates schema text.

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 opens with 'Score any hook text on 5 dimensions with rewrite tips', a specific verb+resource+scope that clearly differentiates from siblings like generate_hooks and score_hooks_batch.

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?

The description implies usage by stating it can score 'any hook text' and references generate's score via 'reproduces generate's score', providing context. However, it does not explicitly say when to prefer this over score_hooks_batch or mention exclusions.

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