Skip to main content
Glama

interfere

Coherent Gate (PAID, x402/USDC). Scores whether your trading-signal paths agree: confidence-weighted long/short/flat consensus, coherence 0-1, and a pass/block gate (pass needs a non-flat consensus and coherence at or above the threshold, default 0.6). Tiers by path count: scout ≤4 $0.01, standard ≤8 $0.05, beast ≤32 $0.25 (defaults). The $0.25 max tier is charged upfront; on the x402 rail the unused difference is recorded as owed (not yet auto-refunded); on the Arc escrow rail (arc_auth_id) only the used tier is captured. Optional ticker pulls extra paths from registered sources before charging. Max 32 paths. Not financial advice.

Input Schema

NameRequiredDescriptionDefault
pathsNoCoherent Gate: AI trading signal paths to check for coherence. Priced tiers: scout ≤4, standard ≤8, beast ≤32 (defaults); >32 hard-rejected.
tickerNoOptional: pull extra paths for this ticker from registered path sources (see docs/COHERENT_GATE_PATH_SOURCES.md).
sourcesNoOptional path-source ids; default = all enabled verified sources. Requires ticker.
arc_auth_idNoArc rail: authId from AuthCaptureEscrow.authorize() for at least the max-tier amount to our receiver. Only the used tier is captured; the rest returns via reclaim() after expiry.
payment_headerNoBase64 X-PAYMENT EIP-3009 payload (standard rail).
wallet_addressNoAgent wallet address (informational).
payment_tx_hashNoBase USDC tx hash (sovereign rail).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / paths / items / properties / confidence / description
      Added value: +"Weight 0-1 this path gets in the consensus."
    • addedInput schema / properties / paths / items / properties / direction / description
      Added value: +"Direction this path calls: long, short, or flat."
    • addedInput schema / properties / paths / items / properties / source / description
      Added value: +"Label for where this signal came from (1-64 chars)."
  2. Changed5 schema fields changed
    • addedInput schema / properties / paths / default
      Added value: +[]
    • removedInput schema / properties / paths / minItems
      Removed value: -1
    • addedInput schema / properties / sources
      Added value: +{
      +  "description": "Optional path-source ids; default = all enabled verified sources. Requires ticker.",
      +  "items": {
      +    "maxLength": 64,
      +    "type": "string"
      +  },
      +  "maxItems": 16,
      +  "type": "array"
      +}
    • addedInput schema / properties / ticker
      Added value: +{
      +  "description": "Optional: pull extra paths for this ticker from registered path sources (see docs/COHERENT_GATE_PATH_SOURCES.md).",
      +  "pattern": "^[A-Z]{1,10}$",
      +  "type": "string"
      +}
    • removedInput schema / required
      Removed value: -[
      -  "paths"
      -]
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses significant behavior: paid tiers, upfront $0.25 max-tier charge, unused difference owed on x402 (not auto-refunded), Arc escrow capturing only the used tier, max 32 paths, and optional ticker pulling extra paths before charging. It stops short of covering failure modes or invalid payment behavior, so a 4 rather than a 5.

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?

The purpose and payment model are front-loaded, and the dense paragraph earns most of its length by covering pricing, charging, and limits. However, it is a single run-on block, and some details like 'Not financial advice' are secondary; a slightly tighter structure would improve readability.

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 complex paid tool with seven parameters, no annotations, and no output schema, the description does a lot: it explains the return concept (consensus, coherence, gate), pricing tiers, payment rails, and path limits. It is nearly complete but does not spell out failure behavior or exact output shape, which keeps it from a 5.

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%, so the baseline is 3; the description still adds meaningful context about path-count pricing tiers, optional ticker pulling extra paths before charging, and arc_auth_id escrow semantics. Some parameters such as sources, wallet_address, and payment_tx_hash are left to the schema, so it does not fully compensate beyond the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific function: scoring whether trading-signal paths agree via confidence-weighted consensus, coherence, and a pass/block gate. The tool name 'interfere' is opaque, but the description immediately clarifies the purpose as 'Coherent Gate'. It does not differentiate itself from siblings like leviathan_interfere or x402_contract, which keeps it from a 5.

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?

Usage is implied through the scoring/gate purpose and payment rails, but there is no explicit statement of when to use this tool versus alternatives or when not to use it. The description explains tiers and rails but leaves the agent to infer the selection context.

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.

Resources