Is the Setix Clearinghouse MCP server down?

mcp-registry/com.setix/clearinghouse · vsetix-v0.4.268

down
Last checked 2026-10-18 21:23 UTC · handshake 111ms

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.

uptime (30d checks)
0%
checks observed
4
outages (90d)
173
tools
54

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

Agent-readiness: F (48/100)

F (48/100): 1 error(s), 7 warning(s) across 54 tool(s); ~25,725 tokens of tool definitions.
Scores higher than 0% of 15,353 MCP servers Glimind has audited.
Its tool list costs an agent ~25,725 tokens per session — more than 95% of servers.
no tool-poisoning patterns
Schemas100
Descriptions82
Safety hints1
Token cost20
Client compatibility20
Protocol100
Reliability0
Stability100

What to fix (9)

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 →

Tools: thread.accept_bid, thread.post_bid, thread.post_principal_delegation, thread.file_dispute, thread.submit_delivery · saves ~4,010 tokens/session

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 →

Tools: thread.accept_bid, thread.agree_delivery_extension, thread.await_owner_events, thread.build_doc, thread.capital_exit and 49 more

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 →

Tools: thread.accept_bid, thread.agree_delivery_extension, thread.await_owner_events, thread.build_doc, thread.capital_exit and 49 more

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 →

Tools: thread.post_ask, thread.post_bid, thread.post_offer, thread.post_principal_delegation, thread.post_principal_delegation_revocation and 8 more

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 →

Tools: thread.await_owner_events, thread.list_protocol_skills, thread.query_asks, thread.query_bids, thread.query_offers and 1 more

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 →

Auto-fix: 54 corrected tool definitions

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

thread.accept_bid 1 change
{
  "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)."
      }
    }
  }
}
thread.agree_delivery_extension 1 change
{
  "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."
      }
    }
  }
}
thread.await_owner_events 1 change
{
  "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 alerted

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.

Passed

Largest tool definitions

Static 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:

Markdown
[![MCP agent-readiness](https://glimind.com/v1/readiness/badge/mcp-registry%2Fcom.setix%2Fclearinghouse.svg)](https://glimind.com/server/mcp-registry%2Fcom.setix%2Fclearinghouse?ref=badge)
HTML
<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>
reStructuredText
.. 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

Tool-definition log

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.

Working alternatives

Tools (54)

Compare: most reliable marketplace servers · most reliable communication servers · most reliable other servers · most reliable finance servers · most reliable data servers

Know before your agent calls it

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.

Add Glimind — free, no signup:

Add to Cursor Add to VS Code

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"
    }
  }
}

FAQ

Is the Setix Clearinghouse MCP server down right now?

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.

How many tools does Setix Clearinghouse MCP server provide?

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.

How do I install Setix Clearinghouse MCP server?

Point your MCP client at this streamable-http endpoint: https://mcp.setix.dev/mcp

Is the Setix Clearinghouse MCP server safe to connect to an AI agent?

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.

Operator of Setix Clearinghouse MCP server?

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.

Feedback
Help us improve