Skip to main content
Glama

Quietwork Payouts

by dev.workers.quietworklabs.qw-payouts
OverviewDiscussionsAdmin

Server Details

Check crypto payout lists (EIP-55, dupes, totals) + Cherum batch-payout link. 0.3% fee disclosed.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: one validates payout data computationally, the other retrieves hosted payout links. An agent can easily tell which to use based on whether it needs validation or a payout URL.

Naming Consistency4/5

Both names use snake_case consistently, which is readable. However, check_payout_list follows a verb_noun pattern while payout_links is noun-only, a minor deviation from a fully predictable convention.

Tool Count3/5

Two tools is thin for the payout domain, even if narrow. The server covers validation and link retrieval, but the small surface may leave agents wanting more supporting operations.

Completeness4/5

The core workflow is covered: validate a payout list and get hosted non-custodial payout links with fee/risk disclosures. Minor gaps exist, such as inspecting supported chains or tokens, but agents can work around them.

Available Tools

2 tools
check_payout_listAInspect

Validate a payout list before paying many wallets: parses 'address,amount' rows (CSV/TSV/space), checks EVM address format and EIP-55 checksums, flags zero/invalid amounts, duplicate and zero addresses, merges duplicates on request, and returns totals, a clean CSV ready to paste into the batch-payout card, and the fee estimate. Pure computation; nothing is stored or sent.

NameRequiredDescriptionDefault
rowsYesOne recipient per line: address,amount (header line optional)
decimalsNoMax decimals allowed for the token (default 6, e.g. USDC)
mergeDuplicatesNoSum amounts for repeated addresses (default false: duplicates are reported as issues)

Output Schema

NameRequiredDescription
okYes
csvYesaddress,amount lines ready for the batch-payout card
noteYes
totalYes
issuesYes
payWithYes
recipientsYes
estimatedFeesYes

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: 'Pure computation; nothing is stored or sent' is exactly the side-effect disclosure an agent needs, and it enumerates what gets flagged vs. merged. It omits whether validation failures throw or are returned as issues, which keeps it from 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?

Single dense sentence, front-loaded with the purpose and the 'before paying' trigger, with the side-effect guarantee closing it. Nearly every clause earns its place, though the list of checks could be tightened.

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 an output schema exists, return-value explanation is optional, yet the description still previews totals, clean CSV, and fee estimate. Combined with the no-side-effect statement and the merge/flag semantics, an agent has enough to call it correctly; only the failure-mode behavior is unstated.

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%, so the schema already documents rows, decimals, and mergeDuplicates. The description reinforces the accepted row formats and merge behavior but adds little parameter-level detail the schema doesn't already provide (e.g., it never mentions the decimals tolerance it enforces). Baseline 3 applies.

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 and resource ('Validate a payout list') plus the full scope of checks performed: CSV/TSV/space parsing, EVM format and EIP-55 checksums, zero/invalid amounts, duplicates. It does not name or differentiate from the sibling payout_links, so it stops short of 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 Guidelines4/5

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

'before paying many wallets' gives a clear triggering context, and 'clean CSV ready to paste into the batch-payout card' clarifies the workflow position. No explicit when-not condition or named alternative is given, so it lacks the routing clarity of a 5.

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. 2 tool updates
    • Changedcheck_payout_list1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "properties": {
+    "csv": {
+      "description": "address,amount lines ready for the batch-payout card",
+      "type": "string"
+    },
+    "estimatedFees": {
+      "properties": {
+        "amount": {
+          "type": "string"
+        },
+        "cherumFeeBps": {
+          "type": "integer"
+        },
+        "gas": {
+          "type": "string"
+        },
+        "note": {
+          "type": "string"
+        },
+        "quietworkFeeBps": {
+          "type": "integer"
+        },
+        "totalBps": {
+          "type": "integer"
+        },
+        "totalWithFees": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "cherumFeeBps",
+        "quietworkFeeBps",
+        "totalBps",
+        "amount",
+        "totalWithFees"
+      ],
+      "type": "object"
+    },
+    "issues": {
+      "items": {
+        "properties": {
+          "issue": {
+            "type": "string"
+          },
+          "line": {
+            "type": "integer"
+          },
+          "value": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "line",
+          "issue"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "note": {
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "payWith": {
+      "type": "string"
+    },
+    "recipients": {
+      "type": "integer"
+    },
+    "total": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "recipients",
+    "total",
+    "estimatedFees",
+    "issues",
+    "csv",
+    "payWith",
+    "note"
+  ],
+  "type": "object"
+}
    • Changedpayout_links1 field changed
      • changedOutput schema / (root)
        Previous value: -nullNew value: +{
+  "$defs": {
+    "fees": {
+      "properties": {
+        "cherumFeeBps": {
+          "type": "integer"
+        },
+        "note": {
+          "type": "string"
+        },
+        "quietworkFeeBps": {
+          "type": "integer"
+        },
+        "totalBps": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "cherumFeeBps",
+        "quietworkFeeBps",
+        "totalBps",
+        "note"
+      ],
+      "type": "object"
+    }
+  },
+  "properties": {
+    "batchPayouts": {
+      "type": "string"
+    },
+    "fanoutSend": {
+      "type": "string"
+    },
+    "fees": {
+      "$ref": "#/$defs/fees"
+    },
+    "operator": {
+      "type": "string"
+    },
+    "page": {
+      "type": "string"
+    },
+    "risk": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "batchPayouts",
+    "fanoutSend",
+    "page",
+    "fees",
+    "risk",
+    "operator"
+  ],
+  "type": "object"
+}
  2. 2 tool updates
    • First observedcheck_payout_list
    • First observedpayout_links

Related MCP Connectors

Related MCP Servers

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