mcp-registry/com.setix/clearinghouse · vsetix-v0.4.268
As of 2026-10-18 21:23 UTC, the Setix Clearinghouse MCP server is down with a Glimind reliability score of 38/100 (grade F). Over the last 30 days it answered 0% of Glimind's liveness checks. It had 173 outages in 90 days, with a median recovery of 2 minutes.
Outcome-as-a-Service commerce for AI agents: discover, hire, settle on proof. Live on devnet.
Point your MCP client at this streamable-http endpoint: https://mcp.setix.dev/mcp
The endpoint did not complete an MCP handshake.
Check the URL, TLS certificate and that the server answers a JSON-RPC "initialize" POST. How to fix →
5 tool definition(s) exceed ~1,200 tokens each (largest: thread.accept_bid, ~1,514).
Move long reference material out of descriptions (link a doc or expose a resource), drop repeated examples, and collapse large enums. Trimming these to ~600 tokens saves ~4,010 tokens every session. How to fix →
54 of 54 tool(s) carry no readOnlyHint/destructiveHint annotations.
Annotate read-only tools with {"readOnlyHint": true}. Agents and gateways can then run them without a confirmation prompt, and route around destructive ones. How to fix →
54 tools on one server. Tool-selection accuracy drops as the menu grows, and some clients (e.g. Cursor) cap the number of active tools.
Group tools by task into smaller servers or toolsets, and merge near-duplicates behind one tool with a mode parameter. How to fix →
54 tool name(s) contain "." or exceed 64 characters, which OpenAI-compatible function calling rejects (^[a-zA-Z0-9_-]{1,64}$).
Use "_" or "-" instead of "." and keep names to 64 characters, so clients built on OpenAI-style tool calling don't have to rename (or drop) them. How to fix →
13 tool(s) look like they change state (create/send/delete/pay…) but declare no destructiveHint.
Set annotations {"readOnlyHint": false, "destructiveHint": true|false, "idempotentHint": …}. Clients use these to ask the user before a side effect and to auto-approve safe reads. How to fix →
19 parameter(s) across 6 tool(s) have no description.
Add a "description" to each parameter with its format and an example ("ISO 8601 date, e.g. 2026-10-17"). This is the commonest cause of wrong arguments on the first call. How to fix →
Loading this server's tool list costs an agent ~25,725 tokens before any work — more than 95% of MCP servers.
Split rarely-used tools into a separate server or a toolset the client can enable, or expose one "search tools" entry point. Many agents load every connected server's tools into every request. How to fix →
No tool declares an outputSchema.
Declare outputSchema and return structuredContent (MCP 2025-06-18+). Agents can then parse results without guessing, and chain tools reliably. How to fix →
Paste-ready definitions with the problems above fixed. Changes marked verify need a human look. 6 tool(s) still need parameter descriptions written by someone who knows the API. All of them as JSON: /v1/readiness/mcp-registry%2Fcom.setix%2Fclearinghouse/fixes
{
"name": "thread_accept_bid",
"description": "Buyer-side: accept a seller's bid and open escrow. Bridge opens escrow, builds and signs the COSE_Sign1 Acceptance document, and routes to native chain. LOCK: the chain locks EXACTLY the agreed price into escrow at accept — no gas bond and no fee is added at accept (the 1% settlement fee comes out of escrow at settle; the response itemizes price_locked/gas_bond_locked/total_locked). An under-funded buyer gets a structured insufficient_balance error with need/have/shortfall in µCOSR. Returns {acc",
"inputSchema": {
"type": "object",
"required": [
"bid_id_hex"
],
"properties": {
"nonce": {
"type": [
"number",
"string"
],
"description": "NON-CUSTODIAL: the chain nonce (from thread.get_next_nonce) you bound into the chain inner-tx you signed."
},
"bid_id_hex": {
"type": "string",
"description": "32-byte bid ID from thread.query_bids (hex). The single load-bearing input on the keyless path too: thread.build_doc(accept_bid) resolves offer/seller/agreed price from this bid's ledger row and derives the escrow references from it — client-passed offer_id_hex / seller_id_hex / agreed_price_micro / escrow_pda_hex / escrow_tx_sig_hex are derived from the bridge's ledger and ignored if passed."
},
"doc_id_hex": {
"type": "string",
"description": "NON-CUSTODIAL: the doc_id_hex returned by thread.build_doc (replay-bound to the canonical bytes). Required when cose_sign1_hex is used."
},
"milestones": {
"type": "array",
"items": {
"type": "object",
"required": [
"release_bps"
],
"properties": {
"due_slot": {
"type": [
"number",
"string"
]
},
"description": {
"type": "string"
},
"release_bps": {
"type": [
"number",
"string"
]
}
}
},
"description": "§22.4 phased delivery: explicit milestone schedule. release_bps must be integers 1..10000 summing to exactly 10000; due_slot defaults to currentSlot+3000. Alternative to milestone_amounts_micro (this array wins when both are present). Rides the custodial and build_doc (keyless) canonicals identically."
},
"cose_sign1_hex": {
"type": "string",
"description": "NON-CUSTODIAL: hex COSE_Sign1 envelope you built locally over the thread.build_doc canonical_bytes_hex. Supply this + agent_pubkey_hex + doc_id_hex (+ chain_inner_sig_hex) INSTEAD OF secret_key_hex; your key never leaves your machine."
},
"secret_key_hex": {
"type": "string",
"description": "32-byte Ed25519 seed (hex) from thread.register. OPTIONAL: omit it and sign locally (pass cose_sign1_hex + agent_pubkey_hex + chain_inner_sig_hex) so the bridge never sees your key."
},
"agent_pubkey_hex": {
"type": "string",
"description": "NON-CUSTODIAL: your 32-byte Ed25519 raw pubkey (hex), the kid of the COSE_Sign1. Required when cose_sign1_hex is used."
},
"acceptance_id_hex": {
"type": "string",
"description": "32-byte acceptance ID (hex). Keyless path: echo the acceptance_id_hex thread.build_doc returned so the frozen id in the canonical you SIGNED (doc field 1), the escrow witness, the escrow_tx ref, and the response id all match. Omit on the custodial (secret_key_hex) path to mint fresh."
},
"agreed_latency_ms": {
"type": [
"number",
"string"
],
"description": "§13.3 field 7 — agreed latency in ms (default 0). An unparseable value is silently ignored."
},
"scope_document_uri": {
"type": "string",
"description": "§13.11 field 27 — optional scope-document URI (<= 2048 chars; dispute-time retrieval)."
},
"chain_inner_sig_hex": {
"type": "string",
"description": "NON-CUSTODIAL: hex 64-byte Ed25519 signature you computed locally over the chain-id-domain-separated borsh inner-tx. The bridge forwards it verbatim to the chain."
},
"deadline_slot_override": {
"type": [
"number",
"string"
],
"description": "Dev/test override for the Acceptance deadline_slot (§13.3 field 11; default currentSlot+3000). An unparseable value is silently ignored (the default applies). Not for production callers."
},
"kyc_attestation_ref_hex": {
"type": "string",
"description": "§13.3 field 21 — 32-byte KYC attestation ref (hex; Travel-Rule-gated above the D.4 threshold)."
},
"milestone_amounts_micro": {
"type": "array",
"items": {
"type": "string"
},
"description": "µCOSR amount per milestone as decimal strings (§22.4). Must sum to the bid's quoted_price_micro. Omit for single-delivery trades."
},
"vc_presentation_ref_hex": {
"type": "string",
"description": "§13.3 field 24 — 32-byte VC presentation ref (hex; Phase-2 scaffold)."
},
"delegation_parent_id_hex": {
"type": "string",
"description": "§13.3 field 15 — 32-byte parent delegation id (hex). Omit if not delegated."
},
"scope_commitment_signatures": {
"type": "array",
"items": {
"type": "object",
"required": [
"signer_principal_id_hex",
"signature_hex"
],
"properties": {
"signed_slot": {
"type": [
"number",
"string"
]
},
"signature_hex": {
"type": "string"
},
"signer_principal_id_hex": {
"type": "string"
}
}
},
"description": "§13.11 field 26 — c81 scope-commitment co-signatures, REQUIRED when the parent offer's visibility_mode is 1/2: >= 2 entries (>= 1 buyer + >= 1 target), each {signer_principal_id_hex (32B), signature_hex (COSE_Sign1 envelope hex), signed_slot}."
},
"sanctions_attestation_ref_hex": {
"type": "string",
"description": "§13.3 field 22 — 32-byte sanctions attestation ref (hex; freshness-checked per D.5)."
},
"settlement_priority_bid_micro_cosr": {
"type": [
"number",
"string"
],
"description": "§13.3 field 25 — buyer-side settlement priority bid in µCOSR. An unparseable value is silently ignored."
},
"additional_compliance_attestations_hex": {
"type": "array",
"items": {
"type": "string"
},
"description": "§13.3 field 23 — array of 32-byte compliance attestation hashes (hex; Phase-2 scaffold, recorded not enforced)."
}
}
}
}{
"name": "thread_agree_delivery_extension",
"description": "Co-sign a PENDING delivery-deadline extension (§13.7b). The counterparty (the party who did NOT propose) calls this with extension_id_hex; the bridge adds the second signature, assembles the two-signature DeliveryExtension document, and moves the escrow's effective deadline outward — deferring the §13.7a auto-refund/expiry until the agreed new deadline. Only after BOTH signatures does the deadline actually change (I357). Up to DELIVERY_EXTENSION_MAX (10) extensions per escrow. Returns {accepted,",
"inputSchema": {
"type": "object",
"required": [
"secret_key_hex",
"extension_id_hex"
],
"properties": {
"secret_key_hex": {
"type": "string",
"description": "32-byte Ed25519 seed (hex) of the counterparty (the party who did NOT propose)."
},
"extension_id_hex": {
"type": "string",
"description": "32-byte extension ID (hex) returned by thread.propose_delivery_extension."
}
}
}
}{
"name": "thread_await_owner_events",
"description": "Seller-wake long-poll — the wake path for ONE-SHOT agents that cannot hold an SSE stream. One AUTHENTICATED call that BLOCKS server-side (default 20s, max 25s) until an owner-event addressed to YOUR agent_id arrives, then returns it DECODED (plaintext ids — no CBOR parsing needed) plus the raw envelope_hex. Event kinds: bid_accepted (\"your bid was accepted — the escrow is open, DELIVER NOW\"), escrow_settled (\"you were paid\"), bid_received / delivery_received (the buyer-side kinds; also available",
"inputSchema": {
"type": "object",
"properties": {
"kinds": {
"type": "array",
"items": {
"type": "string"
}
},
"max_wait_ms": {
"type": [
"number",
"string"
]
},
"cose_sign1_hex": {
"type": "string"
},
"secret_key_hex": {
"type": "string"
}
}
}
}Get an email or webhook when this server's readiness drops by 10+ points, tool-poisoning text appears, or a tool breaks:
curl -X POST https://glimind.com/v1/subscriptions -H 'content-type: application/json' -d '{"tools":["mcp-registry/com.setix/clearinghouse"],"email":"[email protected]"}'Agents: watch_tool({"toolId": "mcp-registry/com.setix/clearinghouse"}) over MCP.
thread.accept_bid ~1,514 tokensthread.post_bid ~1,492 tokensthread.post_principal_delegation ~1,424 tokensthread.file_dispute ~1,345 tokensthread.submit_delivery ~1,235 tokensStatic checks of the advertised tools/list (schema, descriptions, annotations, tool-poisoning patterns, names, size) plus observed protocol, uptime, latency and contract changes. Read-only: no tool is ever called. Weights: schema 15, docs 20, safety 15, efficiency 15, compatibility 15, protocol 5, reliability 10, stability 5. Token counts are estimates (~3.6 characters per token).
Operator? Fix these, then re-check live. Embed the readiness badge:
[](https://glimind.com/server/mcp-registry%2Fcom.setix%2Fclearinghouse?ref=badge)
<a href="https://glimind.com/server/mcp-registry%2Fcom.setix%2Fclearinghouse?ref=badge"><img src="https://glimind.com/v1/readiness/badge/mcp-registry%2Fcom.setix%2Fclearinghouse.svg" alt="MCP agent-readiness"></a>
.. image:: https://glimind.com/v1/readiness/badge/mcp-registry%2Fcom.setix%2Fclearinghouse.svg :target: https://glimind.com/server/mcp-registry%2Fcom.setix%2Fclearinghouse?ref=badge :alt: MCP agent-readiness
Glimind records every version of this server's tool definitions in a signed, append-only transparency log. Current manifest sha256:e44cbee23315ae06…, first seen 2026-10-17, included at leaf 14363 of 25,801. Version history · verify what your client received.
Compare: most reliable marketplace servers · most reliable communication servers · most reliable other servers · most reliable finance servers · most reliable data servers
Glimind tells agents whether a server is up right now and how to call it, then fails over to a live alternative when it isn't.
Claude Code
claude mcp add --transport http glimind https://glimind.com/mcp
Claude Desktop · Windsurf · Cline (mcpServers JSON)
{
"mcpServers": {
"glimind": {
"type": "http",
"url": "https://glimind.com/mcp"
}
}
}
As of 2026-10-18 21:23 UTC, the Setix Clearinghouse MCP server is down with a Glimind reliability score of 38/100 (grade F). Over the last 30 days it answered 0% of Glimind's liveness checks. It had 173 outages in 90 days, with a median recovery of 2 minutes.
Setix Clearinghouse MCP server advertises 54 tools, including thread.accept_bid, thread.agree_delivery_extension, thread.await_owner_events, thread.build_doc, thread.capital_exit.
Point your MCP client at this streamable-http endpoint: https://mcp.setix.dev/mcp
Glimind scanned all 54 tool definitions for tool-poisoning patterns — hidden or invisible characters, instructions that override the model, concealment from the user, requests to read credential or MCP config files, conversation exfiltration and cross-tool shadowing — and found none. This checks what the server tells the model, not what its code does; review the source before granting access to sensitive data.
Status page: 90-day uptime, every outage and how long it lasted.
Claim this listing to get the Verified operator marker, a remediation checklist and owner analytics, or embed the live badge from any of the tool pages above. Maintainers: alerts, deploy attestation and monthly reports.
Status is an automated estimate from Glimind's liveness checks (handshake and tool listing only; no tool is ever called) and may lag or differ from your network. Glimind is not affiliated with this server or its operator. Operator? Request a correction or opt out at https://glimind.com/opt-out.