Skip to main content
Glama
JevGuard MCP Server

JevGuard MCP Server

by seb4ez

jevguard_cache_fingerprint

Compute a stable SHA-256 fingerprint from state and questions, masking volatile keys like timestamps to enable deterministic caching.

Instructions

Calculates a canonical SHA-256 fingerprint from state and questions with volatile key masking (timestamp, trace_id, request_id) for 0-token deterministic caching.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>"
    },
    "name": "jevguard_cache_fingerprint"
  }
}

Input Schema

NameRequiredDescriptionDefault
modelNoTarget model identifier (default: jev-latest).jev-latest
stateYesState payload dictionary to include in fingerprint computation.
questionsNoQuestion definitions dictionary (optional).
ignore_keysNoList of volatile keys to mask in addition to standard defaults.
auto_inject_escapesNoWhether to consider escape injection logic when computing fingerprint (default: true).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.0.1
    • changedInput schema / properties / questions / description
      Previous value: -"Question definitions dictionary or list."New value: +"Question definitions dictionary (optional)."
    • removedInput schema / properties / questions / oneOf
      Removed value: -[
      -  {
      -    "type": "object"
      -  },
      -  {
      -    "type": "array"
      -  }
      -]
    • addedInput schema / properties / questions / type
      Added value: +"object"
    • changedInput schema / properties / state / description
      Previous value: -"State payload to include in fingerprint computation."New value: +"State payload dictionary to include in fingerprint computation."
    • addedInput schema / properties / state / type
      Added value: +"object"
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior3/5

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

There are no annotations, so the description carries the full behavioral disclosure burden. It transparently explains the computation, masking of volatile keys, and deterministic caching intent, but it does not state the return format, whether the model parameter participates in the fingerprint, or any error/side-effect behavior. For a pure calculation tool this is acceptable but incomplete.

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 a single dense sentence that front-loads the core action and purpose. Every phrase contributes meaning: the algorithm, the inputs, the masking behavior, and the intended caching benefit. No filler or redundancy.

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?

Given the moderate complexity of five parameters and nested objects, the description gives enough context to understand why the tool exists and roughly how it behaves. Since there is no output schema, a note about the exact return format would improve completeness, but 'Calculates a canonical SHA-256 fingerprint' sufficiently implies the output.

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?

Schema description coverage is 100%, giving a baseline of 3. The description adds meaning by explaining that ignore_keys masks volatile keys such as timestamp, trace_id, and request_id, and by framing the overall purpose of the parameters. It does not mention the model parameter's role in the fingerprint, but still adds value beyond the schema.

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 names a specific verb ('Calculates') and resource ('canonical SHA-256 fingerprint from state and questions'), and adds distinguishing details like volatile key masking. It is clearly distinct from the evaluation/safety sibling tools, so an agent can tell what this tool is for 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?

The phrase 'for 0-token deterministic caching' gives a clear intended use context, which helps an agent decide when to invoke this tool. However, it does not explicitly mention alternatives, when not to use it, or how it relates to sibling evaluation tools.

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