Skip to main content
Glama
quokkapix

quokkapix-mcp

Official
by quokkapix
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Verify QuokkaPix agent unlock token

verify_unlock_token

Preflight a paid unlock token before a QuokkaPix run to prevent failed batches. Validates scope, price, currency, and run details without consuming the token, pulling live payment options if omitted.

Instructions

Safely preflight a QuokkaPix paid agent unlock token without consuming it. The browser consumes the one-time unlock only when the paid batch actually starts. If scope, price or currency are omitted, the tool reads live payment options first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoRun mode to verify against the unlock token.
filesNoNumber of files intended for the paid run.
priceNoExpected price string. Defaults to live payment options.
scopeNoExpected QuokkaPix scope. Defaults to live payment options.
tokenYesUnlock token returned by the paid x402 unlock endpoint.
baseUrlNoOptional QuokkaPix site base URL. Defaults to https://quokkapix.com.
surfaceNo
currencyNoExpected currency. Defaults to live payment options.
pdfPagesNo
scenarioNo
productIdNo
transcribeNo
durationSecondsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.6.1
    • addedInput schema / properties / durationSeconds
      Added value: +{
+  "minimum": 0,
+  "type": "number"
+}
    • addedInput schema / properties / pdfPages
      Added value: +{
+  "maximum": 300,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / productId
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / scenario
      Added value: +{
+  "type": "boolean"
+}
    • addedInput schema / properties / surface
      Added value: +{
+  "enum": [
+    "image",
+    "video"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / transcribe
      Added value: +{
+  "type": "boolean"
+}
  2. Changed1 schema field changedv0.4.3
    • removedInput schema / properties / consume
      Removed value: -{
-  "description": "False for preflight verification. True consumes the unlock and should be used only at run start.",
-  "type": "boolean"
-}
  3. Changed9 schema fields changedv0.3.1
    • addedInput schema / properties / baseUrl / description
      Added value: +"Optional QuokkaPix site base URL. Defaults to https://quokkapix.com."
    • addedInput schema / properties / consume / description
      Added value: +"False for preflight verification. True consumes the unlock and should be used only at run start."
    • addedInput schema / properties / currency / description
      Added value: +"Expected currency. Defaults to live payment options."
    • addedInput schema / properties / files / description
      Added value: +"Number of files intended for the paid run."
    • addedInput schema / properties / mode / description
      Added value: +"Run mode to verify against the unlock token."
    • addedInput schema / properties / mode / enum
      Added value: +[
+  "single",
+  "batch",
+  "scenario"
+]
    • addedInput schema / properties / price / description
      Added value: +"Expected price string. Defaults to live payment options."
    • addedInput schema / properties / scope / description
      Added value: +"Expected QuokkaPix scope. Defaults to live payment options."
    • addedInput schema / properties / token / description
      Added value: +"Unlock token returned by the paid x402 unlock endpoint."
  4. First observedv0.3.0

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden, and it delivers the key safety property: the tool does not consume the unlock token, and consumption only happens when the paid batch actually starts. It also discloses that omitted fields trigger a live payment-options read, providing useful conditional behavior beyond the schema.

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?

Two tightly written sentences. The first front-loads the action and safety guarantee, and the second adds important consumption semantics and default behavior. No filler or redundant restatement of the tool name.

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

Completeness2/5

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

For a 13-parameter tool with no annotations, no output schema, and many undocumented parameters, this description is not complete. It does not explain what the verification returns, how invalid tokens fail, which payment/processing sibling to pair it with, or how the remaining parameters affect the verification.

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 description adds meaning to scope, price, and currency by explaining their defaulting behavior via live payment options, which the schema does not mention. However, schema description coverage is only 54%, and several parameters such as surface, pdfPages, scenario, productId, transcribe, and durationSeconds remain undocumented in both schema and description.

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 states a specific action: safely preflight a QuokkaPix paid agent unlock token, and explicitly clarifies that the token is not consumed. This distinguishes it from any tool that would actually redeem or start a paid batch. The sibling list has no other token-verification tool, so the purpose is unambiguous.

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 clearly situates the tool as a preflight step before the paid batch starts, and explains that missing scope, price, or currency will cause it to read live payment options. It does not explicitly name alternatives or exclusions, but no sibling tool overlaps with this verification role.

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

Deploy Server

Other Tools