Skip to main content
Glama
WhiteNightShadow

camoufox-reverse-mcp

by WhiteNightShadow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

verify_signer_offline

Validate signer code offline by running it locally against sample inputs and comparing results to expected values. Identify divergences and pass rates without network calls.

Instructions

Verify a signer against explicit expected values without sending requests.

Args: signer_code: JS expression evaluating to a function receiving sample.input and returning an object. Async functions are supported. Only run code you intend to execute locally; Node vm is not a security boundary. samples: Non-empty list (up to 1000) of {id?, input: object, expected: object}. Each expected object must contain at least one comparison key. compare_params: Optional non-empty list of expected keys. Missing keys are invalid input; missing computed keys fail even if expected is null. runtime: "browser" preserves the current-page default. "node" runs an independent process without launching a browser, supports require of crypto/node:crypto, and needs Node.js on PATH. No runtime fallback. timeout_ms: Node process deadline (1..120000); also the maximum wait for the browser evaluation. A browser timeout does not undo/stop effects.

Returns: total_samples, passed, failed, pass_rate, first_divergence and details. Invalid input returns error before any signer code is executed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
runtimeNobrowser
samplesYes
timeout_msNo
signer_codeYes
compare_paramsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.0
    • addedInput schema / properties / runtime
      Added value: +{
+  "default": "browser",
+  "title": "Runtime",
+  "type": "string"
+}
    • addedInput schema / properties / timeout_ms
      Added value: +{
+  "default": 10000,
+  "title": "Timeout Ms",
+  "type": "integer"
+}
  2. Changed4 schema fields changedv1.1.1
    • removedInput schema / properties / compare_params / anyOf
      Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / compare_params / default
      Removed value: -null
    • addedInput schema / properties / compare_params / items
      Added value: +{
+  "type": "string"
+}
    • addedInput schema / properties / compare_params / type
      Added value: +"array"
  3. Addedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It reveals that code runs locally, Node vm is not a security boundary, browser timeouts do not undo/stop effects, and invalid input fails before signer code executes. This is exceptionally transparent.

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 front-loaded with the core purpose and organized into clear Args/Returns sections. Although lengthy, every sentence earns its place by providing necessary operational or safety detail; there is no fluff or 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?

Given no annotations and no output schema, the description covers all required invocation aspects: input structure, constraints, runtime options, error semantics, security caveats, and return fields. The only minor omission is a formal definition of 'signer', but the sample/expected structure makes it clear enough for correct use.

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

Parameters5/5

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

Schema description coverage is 0%, so the detailed Args section must and does compensate. Every parameter is explained with constraints, defaults, runtime behavior, and edge cases (e.g., compare_params missing keys, samples limits, timeout range). No parameter meaning is left to inference.

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 (verify), resource (signer), and completion criterion (against explicit expected values) along with a distinguishing behavior ('without sending requests'). This makes its purpose clear and differentiates it from sibling browser automation and evaluation tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for offline/local verification and detailed runtime selection guidance (browser vs node, no fallback). However, it does not explicitly name an alternative tool or state when not to use this tool, leaving some inference to the agent.

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