Skip to main content
Glama

Hash Encoding Direct Credits

by io.github.PGhannmmn
OverviewDiscussionsAdmin

Server Details

Deterministic SHA, HMAC, Base64 and JWT decode tools with prepaid direct-USDC API credits on Base.

Ownership verified
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A4.2/5.0

Scored across 8 tools

Disambiguation5/5

Every tool has a clearly distinct purpose: encode vs decode direction, unkeyed 256/512 hashes vs keyed HMAC, JWT inspection, and two separate credit tools (balance vs payment instructions). Descriptions actively cross-reference each other (e.g. 'use hmac_sha256 instead when keyed authentication is required'), eliminating overlap. No two tools could be reasonably confused.

Naming Consistency4/5

Names are uniformly snake_case and readable, but the pattern splits into verb_noun (get_credit_balance, get_payment_info) and codec/algorithm_action (base64_decode, hash_sha256, hmac_sha256, jwt_decode). This is a minor stylistic deviation rather than a real inconsistency, and each name is predictable from its tool's function.

Tool Count5/5

Eight tools is well-scoped for a focused encoding/hashing service plus credit management. Each tool earns its place with no filler, and the surface is neither thin nor bloated.

Completeness4/5

Base64 is covered in both directions and SHA-256/SHA-512 plus HMAC-SHA256 are present, which covers the core crypto/encoding workflow along with payment info and balance checks. Minor gaps exist: no HMAC-SHA512 despite SHA-512 being offered, and JWT is decode-only with no verify or encode, though decode-only is a deliberate security choice.

Available Tools

8 tools
base64_decodeBase64 decodeA
Destructive
Inspect

Decode a standard Base64 string into UTF-8 text. Use this only when the decoded bytes are expected to be valid UTF-8; this tool is not for arbitrary binary output. Base64 is reversible encoding, not encryption. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesStandard Base64 text to decode, maximum 65,536 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

The annotations are unusually noisy here (readOnlyHint=false, destructiveHint=true, idempotentHint=false for what is a pure transformation), and the description supplies genuinely useful context the annotations do not: a 1-credit cost and the clarification that Base64 is reversible encoding rather than encryption. It does not explicitly correct the misleading destructive/readOnly flags, so it adds value but leaves a residual gap.

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?

Three short sentences, front-loaded with the core operation, then the applicability constraint, then the cost. No sentence is redundant and nothing is buried.

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?

An output schema exists, so return-value explanation is unnecessary, and the description covers the operation, the applicability boundary, and the credit cost. Nothing an agent needs to invoke this correctly is missing.

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?

Schema coverage is 100% and the single parameter is fully documented in the schema, including the 65,536-character limit, so the baseline is 3. The description adds no syntax, padding, or charset detail beyond what the schema already provides.

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 verb and resource ('Decode a standard Base64 string into UTF-8 text') and pins the output encoding, which cleanly separates it from base64_encode and the hash/hmac siblings. An agent can identify the operation without opening the schema.

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?

It gives an explicit inclusion condition ('use this only when the decoded bytes are expected to be valid UTF-8') and an explicit exclusion ('not for arbitrary binary output'), which is strong when/when-not guidance. It stops short of naming the sibling to use instead when binary output is needed, so it is clear context rather than a full routing rule.

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

base64_encodeBase64 encodeA
Destructive
Inspect

Encode UTF-8 text as standard Base64. Use this for transport/storage encoding of text bytes; Base64 is reversible encoding, not encryption and not a cryptographic hash. Returns the encoded Base64 string. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesPlain text interpreted as UTF-8, maximum 65,536 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

Beyond the annotations, the description adds two useful behavioral facts: the output is the encoded Base64 string and the call costs 1 credit, plus it clarifies the reversible, non-cryptographic nature of the operation. It does not reconcile the surprising destructiveHint=true annotation with what is described as a pure, reversible transformation, which leaves a mild ambiguity.

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?

Three short sentences, all front-loaded around the core action, with zero filler; the 'not encryption, not a hash' clause is the one bit of extra length and it earns its place by preventing tool misuse.

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?

With an output schema present, return values need not be described, and the input is fully specified in the schema. The description covers purpose, intended use, the non-cryptographic caveat, and the credit cost, which is everything an agent needs to call it correctly.

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?

Schema coverage is 100% and the single parameter is fully documented (UTF-8, max 65,536 characters) in the schema itself. The description reinforces the UTF-8 interpretation and notes the standard Base64 alphabet but adds no syntax or format detail beyond the schema, so the baseline 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 gives a specific verb and resource ('Encode UTF-8 text as standard Base64') and immediately contrasts itself against the hash/encryption siblings, so an agent can distinguish it from hash_sha256 or base64_decode without opening any schema.

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?

'Use this for transport/storage encoding of text bytes' states the intended context, and the clarification that Base64 is not encryption or a cryptographic hash implicitly routes the agent away from the hash_* siblings. It stops short of naming an explicit alternative tool or an exclusion case, so it is clear context rather than full when/when-not guidance.

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

get_credit_balanceGet credit balanceA
Read-onlyIdempotent
Inspect

Check the remaining prepaid API credits for the bearer token configured on this MCP connection. Use this after redeeming a payment when you need to decide whether a protected tool can be called. The bearer token is read from the Authorization header, not from tool arguments. This call is free, does not spend credits, and does not purchase or redeem credits.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare the read-only/idempotent/non-destructive profile, and the description adds non-obvious context on top: the credential is read from the Authorization header rather than tool arguments, and the call is free and never spends, purchases, or redeems credits. That cost/auth behavior is exactly what an agent needs beyond the annotation set.

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?

Three tight sentences ordered purpose, usage, then constraints. Every sentence carries distinct information with no repetition.

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?

With an output schema present, return values need not be described. The description covers identity source, cost implications, and the decision context for calling it, which is everything needed for a zero-argument read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4. The description usefully clarifies that the identity comes from the Authorization header instead of tool arguments, which meaningfully explains why no parameters exist.

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?

States a specific verb and resource ('Check the remaining prepaid API credits') and scopes it to the bearer token of this MCP connection. It is unmistakably distinct from the sibling utility tools (base64_encode, hash_sha256, jwt_decode).

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?

Gives an explicit trigger: 'Use this after redeeming a payment when you need to decide whether a protected tool can be called.' That is real when-to-use guidance, though it does not explicitly contrast against get_payment_info or name a when-not condition.

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

get_payment_infoGet payment informationA
Read-onlyIdempotent
Inspect

Return the complete purchase and redemption instructions for this service's prepaid API credits. Use this before paying or when an agent needs the Base Mainnet network, native USDC contract, receiver address, exact package amount, credit quantity, buyer-gas requirement, or redemption steps. This call is free and does not require a bearer token. It does not return a balance; use get_credit_balance after you already have a redeemed bearer token. This payment scheme is direct USDC credits, not x402.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
assetYesNative Circle USDC contract address on Base Mainnet.
schemeYesPayment scheme identifier: direct-usdc-credits-v1.
chainIdYesEVM chain ID for Base Mainnet.
networkYesCAIP-2 network identifier for Base Mainnet.
packagesYesAvailable prepaid credit packages.
receiverYesPublic wallet address that receives the exact USDC package payment.
redeemFlowYesOrdered manual API steps required to redeem a qualifying payment into API credits.
buyerPaysGasYesWhether the buyer pays the on-chain transaction gas.
purchasePathYesSame-origin browser path for the self-service purchase and redemption flow.
assetDecimalsYesUSDC decimal precision.
x402CompatibleYesWhether this direct-credit flow is x402-compatible.
facilitatorRequiredYesWhether a payment facilitator is required.

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds materially new behavior: the call is free, requires no bearer token, and the payment scheme is direct USDC credits rather than x402. These are exactly the facts an agent needs and that structured fields cannot express.

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 tight sentences with no filler; the core purpose is front-loaded, followed by usage, cost/auth facts, and the sibling handoff. Every sentence carries distinct, actionable information.

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?

Even though an output schema exists (so return values needn't be explained), the description fully covers the agent's decision needs: cost, auth, scope limits, sibling routing, and scheme disambiguation. Nothing required to call this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It usefully enumerates the data the response carries (network, USDC contract, receiver address, amount, credit quantity, gas, redemption steps), which compensates by characterizing output rather than inputs.

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?

States a specific verb and resource ('Return the complete purchase and redemption instructions for prepaid API credits') and explicitly distinguishes itself from the sibling get_credit_balance as well as from the x402 scheme. An agent can identify and differentiate this tool without opening any schema.

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?

Gives explicit when-to-use ('before paying or when an agent needs the Base Mainnet network...') and explicit when-not ('does not return a balance; use get_credit_balance after you already have a redeemed bearer token'). The alternative tool and the selecting condition are both named.

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

hash_sha256SHA-256A
Destructive
Inspect

Create an unkeyed SHA-256 fingerprint of UTF-8 text. Use this for checksums, deduplication, content fingerprints, or integrity comparisons when no shared secret is involved; use hmac_sha256 instead when keyed authentication is required. Returns the 32-byte digest as 64 lowercase hexadecimal characters. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesText to hash, interpreted as UTF-8, maximum 65,536 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.8/5.0
Behavior1/5

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

Annotations declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, but the description describes an unkeyed fingerprint computation that returns a digest, which is inherently non-destructive, read-only, and idempotent. This is an annotation contradiction, so the rubric requires a score of 1 despite the useful output-format and cost notes.

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 are front-loaded with purpose, then usage and the sibling alternative, then output format and cost. Every sentence earns its place and nothing is redundant.

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?

For a simple single-parameter pure function with an output schema, the description covers purpose, usage, the hmac_sha256 alternative, return format, and credit cost. It lacks an explicit read-only/non-destructive clarification that would counter the contradictory annotations, leaving a small but important gap.

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 only parameter, input, is already fully described in the schema as UTF-8 text with a 65,536-character maximum. The description restates UTF-8 but adds no new syntax, format, or constraint details beyond the schema; with 100% schema description coverage, the baseline is 3.

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?

Names a specific verb (Create) and resource (unkeyed SHA-256 fingerprint of UTF-8 text), and distinguishes itself from hmac_sha256 by specifying that no shared secret is involved. An agent can identify the operation without opening the schema.

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?

Gives explicit scenarios for use (checksums, deduplication, content fingerprints, integrity comparisons) and names the alternative hmac_sha256 with the condition that selects it (keyed authentication). This is exactly the when-to-use/when-not-to-use guidance needed.

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

hash_sha512SHA-512A
Destructive
Inspect

Create an unkeyed SHA-512 fingerprint of UTF-8 text. Use this when a 512-bit digest is specifically required for checksums, fingerprints, or compatibility; use hash_sha256 for the more common 256-bit digest and hmac_sha256 when keyed authentication is required. Returns 128 lowercase hexadecimal characters. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
inputYesText to hash, interpreted as UTF-8, maximum 65,536 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Annotations exist, so the bar is lower, and the description adds genuine behavioral context beyond them: the exact output shape ('128 lowercase hexadecimal characters') and the cost ('1 credit'). It does not address the odd safety profile declared by annotations (destructiveHint=true for what is a pure computation), but it also does not contradict it.

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?

Three sentences, all front-loaded: purpose first, then the routing rule, then output/cost facts. Every sentence carries distinct information with no repetition of the title.

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?

An output schema exists, so return values need no explanation, yet the description still states the digest length and character case. Combined with the cost note and sibling routing, an agent has everything needed to call this correctly.

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?

Schema coverage is 100% and the single parameter is fully documented (UTF-8 interpretation, 65,536 max length). The description only restates 'UTF-8 text' and adds no syntax or format detail beyond the schema, so the baseline 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?

States a precise verb and resource ('Create an unkeyed SHA-512 fingerprint of UTF-8 text'), and the scope ('unkeyed') immediately distinguishes it from hmac_sha256. An agent can separate this from hash_sha256 without opening either schema.

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 names the selection condition ('when a 512-bit digest is specifically required for checksums, fingerprints, or compatibility') and routes the agent to two named alternatives with their own conditions (hash_sha256 for the common 256-bit case, hmac_sha256 for keyed authentication). Nothing is left to inference.

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

hmac_sha256HMAC-SHA256A
Destructive
Inspect

Authenticate a UTF-8 message with a UTF-8 secret key using HMAC-SHA256. Use this when you need keyed integrity/authentication with a shared secret; use hash_sha256 instead for an unkeyed checksum or fingerprint. Returns the 32-byte HMAC as 64 lowercase hexadecimal characters. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
keyYesSecret key interpreted as UTF-8 text, maximum 1,024 characters. Do not pass a hex/base64 key unless those literal characters are the intended key bytes.
messageYesMessage interpreted as UTF-8 text, maximum 65,536 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Adds real context beyond the structured fields: output encoding (64 lowercase hex chars representing 32 bytes) and the 1-credit cost, which matters for a metered service. It does not, however, reconcile the annotations' destructiveHint=true / idempotentHint=false with what is described as a pure, deterministic computation, so one behavioral question is left unanswered.

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?

Three tight sentences: operation first, disambiguation second, return format and cost last. Every sentence carries distinct, decision-relevant information with no filler.

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?

An output schema exists, so return-value structure need not be spelled out, yet the description still gives the practical result shape and the credit cost. For a two-parameter crypto utility this is everything an agent needs to call it correctly.

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?

Schema description coverage is 100% and both parameters are fully documented there (UTF-8 interpretation, max lengths). The description's mention of UTF-8 key/message largely restates the schema, so it neither adds meaning nor compensates for a gap; baseline 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?

States a specific verb (authenticate) plus the exact resource/algorithm (HMAC-SHA256 over a UTF-8 message with a UTF-8 key), and explicitly differentiates itself from the sibling hash_sha256. An agent can pick this tool without opening any schema.

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?

Gives an explicit when-to-use rule (keyed integrity/authentication with a shared secret) and names the alternative with the condition that selects it (hash_sha256 for an unkeyed checksum or fingerprint). No inference required.

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

jwt_decodeJWT decodeA
Destructive
Inspect

Decode a compact JWT's header and payload for inspection without verifying its signature. Use this for debugging or reading claims only; never treat the returned claims as authenticated or trusted. The response always reports signatureVerified=false, even when a signature segment is present. Costs 1 credit.

ParametersJSON Schema
NameRequiredDescriptionDefault
tokenYesCompact JWT string in header.payload.signature form, maximum 8,192 characters.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A3.7/5.0
Behavior2/5

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

The description discloses genuinely useful behavior beyond the schema: it never verifies the signature, always reports signatureVerified=false even when a signature segment exists, and costs 1 credit. However, it depicts a pure inspection/read operation while annotations declare readOnlyHint=false and destructiveHint=true, leaving the agent with two conflicting signals about whether the call mutates anything.

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?

Three short sentences, front-loaded with the verb and immediately followed by the usage/trust caveat, then the behavioral guarantee and cost. The only mild redundancy is 'for debugging or reading claims only' overlapping the first sentence's 'for inspection'.

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?

An output schema exists, so return shape need not be explained, and the description still adds the trust caveat, the signatureVerified=false guarantee, and credit cost. The one hole is that it never reconciles its read-only framing with the destructive/readOnly annotations, leaving an agent unsure about side effects.

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?

Schema coverage is 100% and the single token parameter already documents the required header.payload.signature form and the 8,192-character limit. The description adds no new parameter semantics (e.g., handling of unpadded or encrypted JWTs), so the baseline 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?

States a specific verb and resource ('Decode a compact JWT's header and payload') plus the critical scope qualifier 'without verifying its signature'. This cleanly separates it from sibling base64_decode, which does not understand JWT structure or emit signature status.

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?

'Use this for debugging or reading claims only' gives a clear use context and a hard exclusion ('never treat the returned claims as authenticated or trusted'), which is exactly the guidance needed for a security-sensitive decoder. It does not, however, name an alternative sibling (e.g., base64_decode) for non-JWT payloads.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Changedget_payment_info3 fields changed
      • addedOutput schema / properties / purchasePath
        Added value: +{
+  "description": "Same-origin browser path for the self-service purchase and redemption flow.",
+  "type": "string"
+}
      • changedOutput schema / properties / redeemFlow / description
        Previous value: -"Ordered steps required to redeem a qualifying payment into API credits."New value: +"Ordered manual API steps required to redeem a qualifying payment into API credits."
      • changedOutput schema / required
        Previous value: -[
-  "scheme",
-  "network",
-  "chainId",
-  "asset",
-  "assetDecimals",
-  "receiver",
-  "packages",
-  "buyerPaysGas",
-  "facilitatorRequired",
-  "x402Compatible",
-  "redeemFlow"
-]New value: +[
+  "scheme",
+  "network",
+  "chainId",
+  "asset",
+  "assetDecimals",
+  "receiver",
+  "packages",
+  "buyerPaysGas",
+  "facilitatorRequired",
+  "x402Compatible",
+  "purchasePath",
+  "redeemFlow"
+]
  2. 7 tool updates
    • Changedbase64_decode2 fields changed
      • addedInput schema / properties / input / description
        Added value: +"Standard Base64 text to decode, maximum 65,536 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "text": {
+          "description": "Decoded UTF-8 text.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "text",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
    • Changedbase64_encode2 fields changed
      • addedInput schema / properties / input / description
        Added value: +"Plain text interpreted as UTF-8, maximum 65,536 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "base64": {
+          "description": "Standard Base64 representation of the UTF-8 input bytes.",
+          "type": "string"
+        },
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "base64",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
    • Changedget_credit_balance1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "credits": {
+          "description": "Current number of remaining API credits.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "credits"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "error": {
+          "description": "Reason the balance could not be returned, such as a missing or invalid bearer token.",
+          "type": "string"
+        }
+      },
+      "required": [
+        "error"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
    • Changedget_payment_info1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "asset": {
+      "description": "Native Circle USDC contract address on Base Mainnet.",
+      "type": "string"
+    },
+    "assetDecimals": {
+      "description": "USDC decimal precision.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "buyerPaysGas": {
+      "description": "Whether the buyer pays the on-chain transaction gas.",
+      "type": "boolean"
+    },
+    "chainId": {
+      "description": "EVM chain ID for Base Mainnet.",
+      "maximum": 9007199254740991,
+      "minimum": -9007199254740991,
+      "type": "integer"
+    },
+    "facilitatorRequired": {
+      "description": "Whether a payment facilitator is required.",
+      "type": "boolean"
+    },
+    "network": {
+      "description": "CAIP-2 network identifier for Base Mainnet.",
+      "type": "string"
+    },
+    "packages": {
+      "description": "Available prepaid credit packages.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "amountAtomic": {
+            "description": "Exact USDC amount in atomic 6-decimal units.",
+            "type": "string"
+          },
+          "credits": {
+            "description": "Credits issued after successful redemption.",
+            "exclusiveMinimum": 0,
+            "maximum": 9007199254740991,
+            "type": "integer"
+          }
+        },
+        "required": [
+          "amountAtomic",
+          "credits"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "receiver": {
+      "description": "Public wallet address that receives the exact USDC package payment.",
+      "type": "string"
+    },
+    "redeemFlow": {
+      "description": "Ordered steps required to redeem a qualifying payment into API credits.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "scheme": {
+      "description": "Payment scheme identifier: direct-usdc-credits-v1.",
+      "type": "string"
+    },
+    "x402Compatible": {
+      "description": "Whether this direct-credit flow is x402-compatible.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "scheme",
+    "network",
+    "chainId",
+    "asset",
+    "assetDecimals",
+    "receiver",
+    "packages",
+    "buyerPaysGas",
+    "facilitatorRequired",
+    "x402Compatible",
+    "redeemFlow"
+  ],
+  "type": "object"
+}
    • Changedhash_sha2562 fields changed
      • addedInput schema / properties / input / description
        Added value: +"Text to hash, interpreted as UTF-8, maximum 65,536 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "sha256": {
+          "description": "SHA-256 digest as 64 lowercase hexadecimal characters.",
+          "pattern": "^[0-9a-f]{64}$",
+          "type": "string"
+        }
+      },
+      "required": [
+        "sha256",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
    • Changedhash_sha5122 fields changed
      • addedInput schema / properties / input / description
        Added value: +"Text to hash, interpreted as UTF-8, maximum 65,536 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "sha512": {
+          "description": "SHA-512 digest as 128 lowercase hexadecimal characters.",
+          "pattern": "^[0-9a-f]{128}$",
+          "type": "string"
+        }
+      },
+      "required": [
+        "sha512",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
    • Changedjwt_decode2 fields changed
      • addedInput schema / properties / token / description
        Added value: +"Compact JWT string in header.payload.signature form, maximum 8,192 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "header": {
+          "description": "Decoded JWT header JSON value."
+        },
+        "payload": {
+          "description": "Decoded JWT payload JSON value."
+        },
+        "signaturePresent": {
+          "description": "Whether the compact JWT included a non-empty signature segment.",
+          "type": "boolean"
+        },
+        "signatureVerified": {
+          "const": false,
+          "description": "Always false: this tool does not verify JWT signatures.",
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "header",
+        "payload",
+        "signaturePresent",
+        "signatureVerified",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  3. 1 tool update
    • Changedhmac_sha2563 fields changed
      • addedInput schema / properties / key / description
        Added value: +"Secret key interpreted as UTF-8 text, maximum 1,024 characters. Do not pass a hex/base64 key unless those literal characters are the intended key bytes."
      • addedInput schema / properties / message / description
        Added value: +"Message interpreted as UTF-8 text, maximum 65,536 characters."
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "description": "Credits remaining after this successful 1-credit call.",
+          "maximum": 9007199254740991,
+          "minimum": 0,
+          "type": "integer"
+        },
+        "hmacSha256": {
+          "description": "HMAC-SHA256 digest encoded as 64 lowercase hexadecimal characters.",
+          "pattern": "^[0-9a-f]{64}$",
+          "type": "string"
+        }
+      },
+      "required": [
+        "hmacSha256",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    },
+    {
+      "additionalProperties": false,
+      "properties": {
+        "creditsRemaining": {
+          "anyOf": [
+            {
+              "maximum": 9007199254740991,
+              "minimum": 0,
+              "type": "integer"
+            },
+            {
+              "type": "null"
+            }
+          ],
+          "description": "Known remaining credits, or null when no balance can be reported."
+        },
+        "error": {
+          "description": "Human-readable reason the protected tool call failed.",
+          "type": "string"
+        },
+        "status": {
+          "description": "HTTP-style status code for the failure.",
+          "maximum": 9007199254740991,
+          "minimum": -9007199254740991,
+          "type": "integer"
+        }
+      },
+      "required": [
+        "error",
+        "status",
+        "creditsRemaining"
+      ],
+      "type": "object"
+    }
+  ],
+  "type": "object"
+}
  4. 8 tool updates
    • First observedbase64_decode
    • First observedbase64_encode
    • First observedget_credit_balance
    • First observedget_payment_info
    • First observedhash_sha256
    • First observedhash_sha512
    • First observedhmac_sha256
    • First observedjwt_decode

Publisher details

Operator
PGhannmmn · Publisher source
Operator website
https://github.com/PGhannmmn · Publisher source
Vendor relationship
First-party · Publisher source
Documentation
https://hash-encoding-001d.qqqa16521-dce.workers.dev/openapi.json · Publisher source
Trust center
Not available
Restrictions
Protected tools require prepaid direct Base USDC credits. 0.10 USDC buys 100 credits. Buyer pays gas. No x402 facilitator. · Publisher source

Related MCP Connectors

Related MCP Servers

Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources