Skip to main content
Glama

RevClamp MCP Server

by com.revclamp.api
OverviewDiscussionsAdmin

Stripe Dispute Evidence UTF-16 & CE 3.0 Completeness Linter

revclamp_lint_dispute_evidence
Read-onlyIdempotent

Deterministically lint a Stripe dispute evidence[access_activity_log] payload against Stripe's 18,000 UTF-16 code unit (String.prototype.length) ceiling, UTF-8 byte length, non-destructive --- BEGIN REVCLAMP CE3 EVIDENCE --- / --- END REVCLAMP CE3 EVIDENCE --- (or [RevClamp Verified Product Usage Log] / [/RevClamp Verified Product Usage Log]) delimiter markers, existing merchant note preservation, 17,922/17,920-char fixed wrapper capacity threshold (SKIP_POST_PRESERVE_DRAFT), and Visa Compelling Evidence 3.0 (CE 3.0) prior-charge (>= 2) + IP/device overlap qualification. Returns structuredContent containing ok, mode, statelessEphemeralAudit, tenantId, lint, utf16CodeUnits, maxUtf16Ceiling, remainingUtf16Units, withinCeiling, utf8Bytes, nonDestructiveMarkersPresent, merchantNotesPreserved, merchantNotesUtf16CodeUnits, fixedWrapperUtf16CodeUnits, merchantLogAtCapacity, stagingActionWhenAtCapacity, priorMatchedCount, hasIpMatch, hasDeviceMatch, ce3RubricPassed, and overallVerdict.

Input Schema

NameRequiredDescriptionDefault
demoNoSet true to lint a sample preset fixture when evidenceLogText / accessActivityLog is omitted.
presetNoScenario preset to evaluate when custom evidenceLogText / accessActivityLog is omitted (default: 'valid_ce3_non_destructive').valid_ce3_non_destructive
hasIpMatchNoWhether the disputed charge IPv4/IPv6 address matches the historical undisputed charges.
hasDeviceMatchNoWhether the disputed charge device_id fingerprint matches the historical undisputed charges.
evidenceLogTextNoMerged or candidate Stripe dispute evidence[access_activity_log] payload evaluated against the 18,000 UTF-16 code unit ceiling and non-destructive delimiter markers.
accessActivityLogNoAlias for evidenceLogText representing Stripe dispute evidence[access_activity_log] payload.
priorMatchedCountNoNumber of prior undisputed Stripe charges (120d-365d old) with matching customer_id and IP/device fingerprint (Visa CE 3.0 requires >= 2).
priorTransactionsNoOptional historical undisputed Stripe charges (120d-365d prior) evaluated for Visa CE 3.0 two-identifier overlap.
disputedTransactionNoOptional disputed Stripe charge/transaction metadata evaluated against priorTransactions for Visa CE 3.0 qualification.
existingMerchantNotesNoExisting human AE/support notes inside evidence[access_activity_log] that must be preserved.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / accessActivityLog
      Added value: +{
+  "description": "Alias for evidenceLogText representing Stripe dispute evidence[access_activity_log] payload.",
+  "maxLength": 30000,
+  "type": "string"
+}
    • addedInput schema / properties / demo
      Added value: +{
+  "default": false,
+  "description": "Set true to lint a sample preset fixture when evidenceLogText / accessActivityLog is omitted.",
+  "type": "boolean"
+}
    • addedInput schema / properties / disputedTransaction
      Added value: +{
+  "description": "Optional disputed Stripe charge/transaction metadata evaluated against priorTransactions for Visa CE 3.0 qualification.",
+  "type": "object"
+}
    • addedInput schema / properties / preset / default
      Added value: +"valid_ce3_non_destructive"
    • changedInput schema / properties / preset / description
      Previous value: -"Scenario preset to evaluate when custom evidenceLogText is omitted (default: 'valid_ce3_non_destructive')."New value: +"Scenario preset to evaluate when custom evidenceLogText / accessActivityLog is omitted (default: 'valid_ce3_non_destructive')."
    • changedInput schema / properties / preset / enum
      Previous value: -[
-  "valid_ce3_non_destructive",
-  "utf16_overflow_19k",
-  "missing_device_and_overwrite_risk",
-  "custom"
-]New value: +[
+  "valid_ce3_non_destructive",
+  "utf16_overflow_19k",
+  "missing_device_and_overwrite_risk",
+  "custom",
+  "ce3_24k_truncation_trap",
+  "ce3_clean_compacted_14k",
+  "ce3_missing_device_binding_19k"
+]
    • addedInput schema / properties / priorTransactions
      Added value: +{
+  "description": "Optional historical undisputed Stripe charges (120d-365d prior) evaluated for Visa CE 3.0 two-identifier overlap.",
+  "type": "array"
+}
  2. Changed2 schema fields changed
    • changedInput schema / properties / existingMerchantNotes / maxLength
      Previous value: -18000New value: +30000
    • changedInput schema / properties / priorMatchedCount / maximum
      Previous value: -50New value: +100
  3. First observed

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds substantive context: it is deterministic, stateless (statelessEphemeralAudit, tenantId), non-destructive of existing merchant notes, and it discloses the fixed-wrapper capacity threshold plus the SKIP_POST_PRESERVE_DRAFT staging behavior when at capacity. The long field enumeration at the end dilutes rather than deepens this, which keeps it below 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.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The body is a single run-on sentence packing every threshold, delimiter literal, and rule into one clause chain, followed by a bare comma-separated dump of ~22 return field names. Information is present but not front-loaded or grouped, and the return-field list reads as exhaust rather than explanation.

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

Completeness3/5

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

With 10 parameters, nested objects, and no output schema, listing return fields is genuinely useful, and the CE 3.0 rules plus capacity thresholds are covered. However, the returned fields are named without meaning (e.g., overallVerdict, merchantLogAtCapacity), preset semantics and demo/preset override behavior are unexplained, and there is no guidance on which input path to choose.

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%, so the baseline is 3; the description largely restates schema facts (18,000 UTF-16 ceiling, delimiter markers, prior-charge >= 2 with IP/device overlap). It does not resolve the one genuinely ambiguous point the schema leaves open, namely how evidenceLogText and accessActivityLog interact as aliases or when preset overrides custom input.

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?

States a specific verb ('Deterministically lint') and a precisely scoped resource ('a Stripe dispute evidence[access_activity_log] payload') with the exact checks performed (18,000 UTF-16 ceiling, delimiters, CE 3.0 qualification). The purpose is unmistakable, but it never names the closest sibling (revclamp_stage_stripe_dispute_ce3) to draw the boundary explicitly.

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

Usage Guidelines2/5

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

There is no statement of when to call this versus alternatives, no prerequisites, and no exclusions. The mention of 'SKIP_POST_PRESERVE_DRAFT' and a staging action hints that a separate staging tool exists, but the description never routes the agent there or explains the handoff.

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

All RevClamp MCP Server toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources