tech.monarkgate/monark

Est-ce que tech.monarkgate/monark est sûr ?

Au dernier audit MCP Hub, le serveur MCP « tech.monarkgate/monark » est classé « Non encore testé ». Référencé dans l'annuaire. Seul le pentest comportemental fait foi, et il n'a pas encore été exécuté sur ce serveur. Le verdict est réévalué en continu ; consultez la fiche pour l'état à jour.

Méthode : MCP Hub analyse la description de chaque outil (couche 1) et, pour le verdict fort, exécute le serveur dans une micro-VM isolée avec leurres et réseau bloqué (couche 2). On publie des noms et des compteurs, jamais le contenu brut renvoyé par un outil.

Les 4 outils

• attest≈ 669 tokens

  projection of a committed Shōgen-verified witness (Binance BTCUSDT, self-notarized); the verifier is NOT executed at call time.

  Paramètres, retour & exemple (0)

  Exemple d'appel

  {"name": "attest", "arguments": {}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"label": "texte", "price": {}, "provenance": {}}}

• calibrate≈ 500 tokens

  split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right.

  Paramètres, retour & exemple (3)

  Paramètres

  • nMin · integer · requis
    Minimum calibration count (>= 1); n < nMin fails closed to under_calib.
  • alpha · number · requis
    Target miscoverage in the open interval (0,1).
  • scores · array · requis
    Caller-supplied nonconformity scores (BYO: the caller owns the score function; MONARK stays agnostic).

  Exemple d'appel

  {"name": "calibrate", "arguments": {"nMin": 1, "alpha": 1, "scores": []}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"n": 1, "qhat": 1, "alpha": 1, "label": "texte", "method": "texte", "reason": "texte", "scores_sha256": "texte"}}

• cascade≈ 600 tokens

  Estimated liquidable amount from the real UKEMI cascade primitives (imported, never re-implemented): an Eisenberg-Noe clearing of the interbank system (L, e) with alpha=beta=1 yields the largest clearing vector L*; each node is then read as a leveraged position — collateral is its cleared balance-sheet value (external assets plus interbank receipts under L*), debt is its nominal obligations, liquidation threshold K=1 — and liquidableAmount sums the debts of the nodes whose cleared value, once shocked by the caller-carried 24h fraction, no longer covers their obligations. Shocking the whole cleared value is a v0 simplification; no source supports shocking interbank receivables. yhat is that liquidable amount: a monetary quantity in the reference asset, a single point that HIKAE conformalizes downstream — no guarantee, no score. Downstream, no cascade calibration is committed; the gate abstains (under_calib) on this class. This cascade tool is v0, replaced at U-5.

  Paramètres, retour & exemple (4)

  Paramètres

  • L · array · requis
    Nominal interbank liabilities matrix L[i][j] = what node i owes node j. Square, entries >= 0, zero diagonal.
  • e · array · requis
    External assets (liquidation value) per node at the clearing date. One value per node.
  • shock · number · requis
    24h collateral price shock fraction in [0,1] — a declared fixture parameter, not a dynamics model.
  • producedAt · string · requis
    Caller-carried RFC3339 instant, injected for hash stability (D4); the tool reads no clock.

  Exemple d'appel

  {"name": "cascade", "arguments": {"L": [], "e": [], "shock": 1, "producedAt": "texte"}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"yhat": "texte", "task_class": "texte", "produced_at": "texte", "predictor_id": "texte", "schema_version": "texte", "features_digest": "texte"}}

• gate≈ 2845 tokens

  Coverage-gated decision from the real HIKAE L3 policy (commit/defer/abstain) over a caller-carried authorization budget B_t. Dispatches on task_class. The class 'btc-dir-15m' is retired and answers a named refusal. For 'cascade-liquidable-24h' no cascade calibration is committed; the gate abstains (under_calib) on this class. For 'stable-run-velocity-24h' (Narabi: a redemption-flow velocity forecast) the gate holds a committed stable-run velocity calibration for the USDe synthetic-dollar-whitelisted-redeem population (key narabi:persistence-v2@eip155:1/erc20:0x4c9edd5852cd905f086c759e8383e09bff1e68b3) over calm-window redemption flow; coverage is stated under the split-conformal bound of Barber, Candes, Ramdas and Tibshirani 2023 (Thm 2, unit weights): at least 1 − α minus the average total-variation gap between calibration windows and the next one; that gap is not estimated here and the calibration is measured non-stationary across half-years, so 1 − α is the coverage only if that gap is zero (exchangeability), which is not assumed here; no coverage is measured; on that key it requires alpha = 0.1, nMin = 50; for any other population, no stable-run velocity calibration is committed for this population; the gate abstains (under_calib). For 'liquidation-eligible-coverage' (Ukemi: a per-account liquidable-amount class, class A only) the served region is a conformal upper bound on the liquidable amount for the calibrated class; the lower edge is 0 by construction, not a calibrated bound; abstains (under_calib) outside it; this class requires alpha = 0.01, nMin = 100; calibrated on one recorded episode; no coverage is claimed on any other event; the H-3 exchangeability check is a report, a YES licenses nothing more; the bound holds only if yhat was produced by the frozen close-factor rule on a mono-collateral WETH account at the first crossing, which the gate does not check. The 32 kata classes `{btc,eth,bnb,sol}-{dir,range,mae-down,mae-up}-{1h,4h}` are served from their policy tables, which hold no committed calibration row: every well-formed kata call abstains with no region (under_calib, or non_evaluable on a dir lean of exactly 0), and no kata class has an attestation subject. A kata call carries a `predictor_id` of the form `kata:<kataId>@<venue>/<SYMBOL>/<h>` (no bucket, <h> the class horizon), a `features_digest`, alpha = 0.45, nMin = 6 on dir classes and alpha = 0.01, nMin = 299 on the others, tau at most 1 on dir classes, and a `produced_at` on the class horizon grid, received at most 300 s after it; the full request rules are in section 9 of the contract 1.1.0 specification. When the caller instead supplies a `calibration` (its own nonconformity scores plus a `mode`: `interval` ⇒ region [yhat - q̂, yhat + q̂], or `set` ⇒ a conformal set over caller `candidates`), the gate conformalizes against THOSE caller-supplied scores (BYO): split-conformal quantile at miscoverage α over caller-supplied nonconformity scores. MONARK does not see, store, or verify the caller's data or model, and does not validate that the supplied numbers are nonconformity scores of any model. Marginal 1−α coverage holds ONLY for future points exchangeable with the supplied scores; non-exchangeable data (e.g. distribution-shifted or time-ordered) voids it. Never a probability of being right. A caller-carried `attested` price must declare a subject consistent with the committed task class (exact committed-URL membership; BYO classes do not accept `attested` in P1); the attestation is carried by the caller and is not re-verified at call time (the verifier is not executed here); `attest` only projects the committed witness — verify a caller-carried attestation offline with the Shōgen verifier; no temporal binding in P1. No served class has a committed attestation subject (the retired 'btc-dir-15m' held the only one), so any `attested` is refused. The gate only emits a decision; it never calls the named tool.

  Paramètres, retour & exemple (3)

  Paramètres

  • params · object · requis
  • attested · object · optionnel
  • prediction · object · requis

  Exemple d'appel

  {"name": "gate", "arguments": {"params": {}, "prediction": {}}}

  Exemple de retour

  {"content": [{"type": "text", "text": "…"}], "structuredContent": {"tool": "texte", "allow": true, "action": "commit", "intent": "texte", "reason": "covered", "verdict": {}, "request_sha256": "texte", "schema_version": "texte", "remaining_budget": 1}}

C'est votre serveur ?

Revendiquez-le sur l'espace créateur (preuve GitHub, domaine ou npm) pour afficher le badge « propriétaire vérifié » et lancer un pentest comportemental à la demande afin d'obtenir le badge « Vérifié ».

Créer un compte / revendiquer →

Source

https://mcp.monarkgate.tech/mcp