Skip to main content
Glama

quote

Read-only

Read archived generation price and wait metadata without spending. Free.

    Validates the retained input schema and computes its historical price ceiling,
    balance, cap blocker, and wait metadata. It does not authorize or predict a runnable
    operation: generate_hooks is archived and always fails before work or billing.
    Errors: unauthorized, invalid_request, rate_limited.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoGeneration engine and therefore the price: instant (0 base + 1/hook, deterministic templates, sub-second), smart (0 + 2/hook, one LLM call, seconds), research (10 + 4/hook, brief->draft->judge, tens of seconds). Aliases: template|off|quick->instant, llm|on|fast->smart, search|deep|deep_research->research. Omit (or auto) -> smart when an LLM key is configured, else instant.
countNoHistorical generation count, 1-25. It drives compatibility price metadata only; the archived writer cannot run.
topicYesHistorical generation topic, 3-200 chars. This compatibility tool validates stored-client inputs but cannot authorize a writer.
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
archetypesNoRestrict generation to these archetype ids (see list_archetypes). Omit to let the engine spread across archetypes, which is what you want unless you are deliberately narrowing a deck.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNoThe hook count quoted.
topicNoThe topic as validated (echoed back).
blockerNoNull when affordable. Otherwise the SAME typed error block generate_hooks would have returned ({code, message, retriable, details, ...}), whose details.hint names the exact fix.
formulaNoThe exact charge formula, so you can predict any other count.
platformNoThe platform quoted.
operationNoThe operation this quote prices ('generate_hooks').
affordableNotrue when a generate with these arguments would pass every pre-flight gate (balance AND any daily account/key spend cap). Branch on THIS.
base_priceNoFixed part of the charge for pricing_mode.
credits_maxNoThe CEILING: base_price + price_per_hook * count. The real charge bills hooks RETURNED, so a short deck costs less. Never more than this.
pricing_modeNoThe tier that will actually be BILLED after aliases and auto were resolved: instant|smart|research. This, not mode_requested, is what the price belongs to.
credits_shortNoHow many credits you are missing; 0 when affordable. Against a daily cap this is the gap to the remaining daily headroom, not to your balance.
expected_waitNo{mode, p50_ms, p90_ms, source} for pricing_mode. Compare p90_ms against your own patience to choose sync vs start_generate_job + wait_for_job.
llm_configuredNoWhether this deployment has an LLM key. false means smart/research are unavailable and mode=auto resolves to instant.
mode_requestedNoThe mode string you passed, before resolution; null if omitted.
price_per_hookNoPer-hook part of the charge for pricing_mode.
recommendationNoOne sentence naming the next call to make.
credits_remainingNoYour balance right now.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only indicate readOnlyHint=true, while the description adds substantial behavioral details: it validates the retained input schema, computes historical price ceiling, balance, cap blocker, and wait metadata, and stresses that no billing occurs. It also specifies possible errors (unauthorized, invalid_request, rate_limited), which is beyond the annotations. No contradiction.

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?

The description is short, front-loads the purpose in the first sentence, then adds necessary limitations and error details. Each sentence contributes value without redundancy, making it highly concise and well-structured.

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 the output schema exists (the agent can infer return values) and the description covers purpose, limitations, and errors, the tool is adequately specified for an agent to invoke it correctly. The only minor gap is not explicitly naming sibling pricing tools, but the overall context is complete enough.

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?

All six parameters have rich descriptions in the input schema (100% coverage), including defaults, enums, and constraints. The main tool description does not add any additional parameter-specific meaning beyond saying it validates the retained input schema, so a baseline 3 is appropriate.

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 clearly states a specific action and resource: 'Read archived generation price and wait metadata without spending. Free.' It further clarifies that it computes historical price ceiling, balance, cap blocker, and wait metadata, and explicitly distinguishes itself from generate_hooks by noting that tool is archived and always fails. This leaves no ambiguity about the tool's function.

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 gives clear context that this is a free, read-only historical quote tool for an archived generator. It explicitly says it does not authorize or predict a runnable operation, which implies it should not be used for live generation, but it does not name alternatives like get_estimates or pricing. Thus there is clear context but no explicit when-not-to-use vs those siblings.

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