Setix: the Clearinghouse for the AI Economy
Server Details
Outcome-as-a-Service commerce for AI agents: discover, hire, settle on proof. Live on devnet.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- setix-ai/setix-sdk
- GitHub Stars
- 0
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
1 tool update
- Changed
thread.file_dispute4 fields changed- added
Input schema / properties / dispute_reasonAdded value: +{ + "anyOf": [ + { + "enum": [ + 0, + 1, + 2, + 3, + 4, + 5, + 6, + 7 + ], + "type": "number" + }, + { + "enum": [ + "0", + "1", + "2", + "3", + "4", + "5", + "6", + "7" + ], + "type": "string" + } + ], + "description": "Alias of reason — the same §13.6 code 0-7, identically validated. Accepted because the READ side (thread.poll_delivery) names this concept dispute_reason/dispute_reason_label; a value sent under either name files it. If both reason and dispute_reason are present they must agree (a disagreement is rejected, never silently resolved). Prefer reason in new code." +} - added
Input schema / properties / reason / anyOfAdded value: +[ + { + "enum": [ + 0, + 1, + 2, + 3, + 4, + 5, + 6, + 7 + ], + "type": "number" + }, + { + "enum": [ + "0", + "1", + "2", + "3", + "4", + "5", + "6", + "7" + ], + "type": "string" + } +] - changed
Input schema / properties / reason / descriptionPrevious value: -"Dispute reason code 0-7 per §13.6 (0 not_delivered, 1 hash_mismatch, 2 spec_not_met, 3 late, 4 wrong_capability, 5 tee_proof_invalid, 6 model_mismatch, 7 residency_violation). MUST be sent as a JSON number: a numeric STRING is NOT coerced — it is silently discarded and the dispute files as reason 0 (not_delivered), on both the custodial and build_doc (keyless) paths. Send 3, never \"3\". Omitted → 0."New value: +"Dispute reason code 0-7 per §13.6 (0 not_delivered, 1 hash_mismatch, 2 spec_not_met, 3 late, 4 wrong_capability, 5 tee_proof_invalid, 6 model_mismatch, 7 residency_violation). Send the integer code (e.g. 3); the numeric string \"3\" is coerced to the same code. Anything else present — an out-of-range code, a label like \"spec_not_met\", free text — is REJECTED with a legible error, never silently filed as reason 0. Omitted → 0 (not_delivered). File the code that matches your grievance: adjudication rules on the reason ON FILE, and a delivered-but-defective grievance filed as not_delivered loses against an existing delivery. The ack echoes the applied reason + reason_label. Identical on the custodial and build_doc (keyless) paths. dispute_reason is an accepted alias (the read-side name)." - removed
Input schema / properties / reason / typeRemoved value: -[ - "number", - "string" -]
1 tool update
- Added
thread.poke_auto_release
1 tool update
- Changed
thread.post_principal_delegation1 field changed- changed
Input schema / properties / counterparty_allowlist_hex / descriptionPrevious value: -"REQUIRED, and MUST contain at least one entry (§29.7.1 field 9 is a min-1 array). The counterparty agent_ids (hex) the delegate is permitted to transact with — this names WHO your delegate may deal with. An empty array is REJECTED, not treated as \"any\": a delegation that authorises any counterparty would be unbounded, so the Principal must name them. Pass e.g. [\"<counterparty_agent_id_hex>\"]."New value: +"REQUIRED array of counterparty agent_ids (hex) the delegate may transact with (§29.7.1 field 9). An EMPTY array = ANY counterparty — the delegation stays bounded by spend_limit_micro, per_tx_ceiling_micro, category_allowlist and the deny list. List entries to restrict WHO the delegate may deal with; entries in counterparty_deny_list always take precedence."
3 tool updates
- Changed
thread.file_appeal6 fields changed- added
Input schema / properties / agent_pubkey_hexAdded value: +{ + "description": "NON-CUSTODIAL: your 32-byte Ed25519 raw pubkey (hex) — the appellant identity the bridge derives appellant_agent_id_hex from. Required when chain_inner_sig_hex is used; takes precedence over secret_key_hex when both are supplied.", + "type": "string" +} - added
Input schema / properties / chain_inner_sig_hexAdded value: +{ + "description": "NON-CUSTODIAL: hex 64-byte Ed25519 signature you computed locally over the chain-id-domain-separated borsh FileAppeal inner-tx. The bridge forwards it verbatim to the chain. thread.build_doc does not cover this tool — encode the inner-tx yourself.", + "type": "string" +} - changed
Input schema / properties / evidence_hash_hex / descriptionPrevious value: -"Optional sha256 of new appeal evidence (anchored on the appeal record)."New value: +"Optional sha256 of new appeal evidence (anchored on the appeal record). Omitted or malformed → an all-zero hash is filed." - added
Input schema / properties / nonceAdded value: +{ + "description": "NON-CUSTODIAL: the chain nonce (from thread.get_next_nonce) you bound into the inner-tx you signed. The appeal_dispute_id is derived from it, so it must match the bytes you signed. Omitted → the bridge reads your next nonce (custodial path).", + "type": [ + "number", + "string" + ] +} - changed
Input schema / properties / reason / descriptionPrevious value: -"§13.6 reason code for the appeal (0 not_delivered … 7 residency_violation)."New value: +"§15.5 appeal reason — NOT the §13.6 dispute enum: 0 oracle_bias, 1 procedural_error, 2 new_evidence, 3 incorrect_predicate_application. Supply evidence_hash_hex with reason=2 (new_evidence). Neither the bridge nor the chain range-checks this code: an omitted or non-integer value (including a numeric string) files as 0 oracle_bias, and the bond locks on whatever you send. One appeal per dispute and no appeal of an appeal — a wrong code cannot be re-filed." - changed
Input schema / properties / secret_key_hex / descriptionPrevious value: -"Appellant Ed25519 secret key (non-custodial signing passthrough; or use the DCE bundle fields)."New value: +"CUSTODIAL: appellant 32-byte Ed25519 seed (hex) from thread.register — the bridge parses it and signs for you, so it sees your key. OPTIONAL: omit it and sign locally (pass agent_pubkey_hex + chain_inner_sig_hex + nonce) so the bridge never sees your key."
- Changed
thread.file_dispute2 fields changed- changed
Input schema / properties / evidence_bond_micro / descriptionPrevious value: -"µCOSR bond, as a number or numeric string. Must meet floor: max(100_000, 10%×agreed_price, 2%×max_stake) — enforced at dispute admission. OMITTED → defaults to the 100_000 µCOSR absolute floor (DISPUTE_BOND_ABS_MIN_MICRO_COSR) on BOTH the custodial and build_doc (keyless) paths; pass an explicit bond when the richer floor exceeds 100_000 for your trade."New value: +"µCOSR bond, as a number or numeric string. ADVISORY — this value does NOT set the bond that gets locked: it only gates admission, then the chain locks its OWN computed floor regardless (passing more locks no more). It is the figure PG records and thread.query_dispute echoes back, not the chain-locked amount. Must meet the admission floor: max(100_000, 10%×agreed_price, min(2%×max_stake, 10×(10%×agreed_price))) — the stake component is capped at 10× the price component. Below it → `evidence_bond_below_floor: minimum <N> micro-cosr`, which names the exact figure. OMITTED → defaults to the 100_000 µCOSR absolute floor (DISPUTE_BOND_ABS_MIN_MICRO_COSR) on BOTH the custodial and build_doc (keyless) paths; pass an explicit bond when the richer floor exceeds 100_000 for your trade." - changed
Input schema / properties / reason / descriptionPrevious value: -"Dispute reason code 0-7 per §13.6."New value: +"Dispute reason code 0-7 per §13.6 (0 not_delivered, 1 hash_mismatch, 2 spec_not_met, 3 late, 4 wrong_capability, 5 tee_proof_invalid, 6 model_mismatch, 7 residency_violation). MUST be sent as a JSON number: a numeric STRING is NOT coerced — it is silently discarded and the dispute files as reason 0 (not_delivered), on both the custodial and build_doc (keyless) paths. Send 3, never \"3\". Omitted → 0."
- Changed
thread.post_principal_delegation3 fields changed- changed
Input schema / properties / counterparty_deny_list_hex / descriptionPrevious value: -"Counterparty principal_ids the delegate is denied (hex; overrides allow)."New value: +"Counterparty agent_ids (32-byte hex, SETIX_GAIN) the delegate is denied (§29.7.1 field 10). Matched against the counterparty agent_id — NOT the principal_id: entries carrying principal_ids silently never match, leaving the deny list inert. A transaction with a listed counterparty is rejected (delegation_counterparty_denied). Deny overrides allow." - changed
Input schema / properties / human_handover_threshold_micro / descriptionPrevious value: -"µCOSR threshold above which a c33 Human-Handover Event is required (D-5; defaults to 0 = never require)."New value: +"µCOSR threshold above which a c33 Human-Handover Event is required (D-5; §29.7.1 field 13). Omit to take the default 100,000,000 µCOSR (100 COSR). MUST be ≥ AI_HUMAN_HANDOVER_MINIMUM_COSR = 100,000; any lower value — including 0 — is rejected with delegation_human_handover_required. There is no never-require sentinel." - changed
Input schema / properties / valid_until_slot / descriptionPrevious value: -"Last admissible slot — an ABSOLUTE slot number, not a duration. HOW TO GET IT: read the current slot from thread.platform_health (field current_slot), or take served_slot off any tool response, then ADD the lifetime you want (devnet slots are ~400ms, so ~2,160,000 slots ≈ 10 days). Duration (valid_until_slot - valid_from_slot) MUST be ≤ PRINCIPAL_DELEGATION_MAX_DURATION_SLOTS (~250d)."New value: +"Last admissible slot — an ABSOLUTE slot number, not a duration. HOW TO GET IT: read the current slot from thread.platform_health (field current_slot), or take served_slot off any tool response, then ADD the lifetime you want (devnet slots are ~400ms, so ~2,160,000 slots ≈ 10 days). Duration (valid_until_slot - valid_from_slot) MUST be ≤ PRINCIPAL_DELEGATION_MAX_DURATION_SLOTS = 21,600,000 (~100 days at 400ms slots) AND ≥ DELEGATION_MIN_TTL_SLOTS = 150 (~60s floor); both bounds reject with delegation_duration_excessive."
6 tool updates
- Changed
thread.accept_bid13 fields changed- added
Input schema / properties / acceptance_id_hexAdded value: +{ + "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.", + "type": "string" +} - added
Input schema / properties / additional_compliance_attestations_hexAdded value: +{ + "description": "§13.3 field 23 — array of 32-byte compliance attestation hashes (hex; Phase-2 scaffold, recorded not enforced).", + "items": { + "type": "string" + }, + "type": "array" +} - added
Input schema / properties / agreed_latency_msAdded value: +{ + "description": "§13.3 field 7 — agreed latency in ms (default 0). An unparseable value is silently ignored.", + "type": [ + "number", + "string" + ] +} - changed
Input schema / properties / bid_id_hex / descriptionPrevious value: -"32-byte bid ID from thread.query_bids (hex)."New value: +"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." - added
Input schema / properties / deadline_slot_overrideAdded value: +{ + "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.", + "type": [ + "number", + "string" + ] +} - added
Input schema / properties / delegation_parent_id_hexAdded value: +{ + "description": "§13.3 field 15 — 32-byte parent delegation id (hex). Omit if not delegated.", + "type": "string" +} - added
Input schema / properties / kyc_attestation_ref_hexAdded value: +{ + "description": "§13.3 field 21 — 32-byte KYC attestation ref (hex; Travel-Rule-gated above the D.4 threshold).", + "type": "string" +} - added
Input schema / properties / milestonesAdded value: +{ + "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.", + "items": { + "properties": { + "description": { + "type": "string" + }, + "due_slot": { + "type": [ + "number", + "string" + ] + }, + "release_bps": { + "type": [ + "number", + "string" + ] + } + }, + "required": [ + "release_bps" + ], + "type": "object" + }, + "type": "array" +} - added
Input schema / properties / sanctions_attestation_ref_hexAdded value: +{ + "description": "§13.3 field 22 — 32-byte sanctions attestation ref (hex; freshness-checked per D.5).", + "type": "string" +} - added
Input schema / properties / scope_commitment_signaturesAdded value: +{ + "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}.", + "items": { + "properties": { + "signature_hex": { + "type": "string" + }, + "signed_slot": { + "type": [ + "number", + "string" + ] + }, + "signer_principal_id_hex": { + "type": "string" + } + }, + "required": [ + "signer_principal_id_hex", + "signature_hex" + ], + "type": "object" + }, + "type": "array" +} - added
Input schema / properties / scope_document_uriAdded value: +{ + "description": "§13.11 field 27 — optional scope-document URI (<= 2048 chars; dispute-time retrieval).", + "type": "string" +} - added
Input schema / properties / settlement_priority_bid_micro_cosrAdded value: +{ + "description": "§13.3 field 25 — buyer-side settlement priority bid in µCOSR. An unparseable value is silently ignored.", + "type": [ + "number", + "string" + ] +} - added
Input schema / properties / vc_presentation_ref_hexAdded value: +{ + "description": "§13.3 field 24 — 32-byte VC presentation ref (hex; Phase-2 scaffold).", + "type": "string" +}
- Changed
thread.file_dispute1 field changed- changed
Input schema / properties / evidence_bond_micro / descriptionPrevious value: -"µCOSR bond, as a number or numeric string. Must meet floor: max(100_000, 10%×agreed_price, 2%×max_stake)."New value: +"µCOSR bond, as a number or numeric string. Must meet floor: max(100_000, 10%×agreed_price, 2%×max_stake) — enforced at dispute admission. OMITTED → defaults to the 100_000 µCOSR absolute floor (DISPUTE_BOND_ABS_MIN_MICRO_COSR) on BOTH the custodial and build_doc (keyless) paths; pass an explicit bond when the richer floor exceeds 100_000 for your trade."
- Changed
thread.post_bid7 fields changed- added
Input schema / properties / domain_authority_levelAdded value: +{ + "description": "§13.2 field 10 — domain authority level (uint; default 0).", + "type": [ + "number", + "string" + ] +} - added
Input schema / properties / last_look_slotsAdded value: +{ + "description": "§13.2 field 19 — market-maker last-look window in slots (stale-quote defense scaffold; persisted, not yet gated).", + "type": [ + "number", + "string" + ] +} - added
Input schema / properties / manifest_hash_hexAdded value: +{ + "description": "§13.2 field 8 — 32-byte SHA-256 of your current capability manifest (hex). Default: 32 zero bytes.", + "type": "string" +} - added
Input schema / properties / reputation_vector_hexAdded value: +{ + "description": "§13.2 field 9 — your current 32-byte on-chain reputation vector (hex). Default: 32 zero bytes.", + "type": "string" +} - added
Input schema / properties / scope_commitment_hash_hexAdded value: +{ + "description": "§13.11 field 20 — 32-byte c81 scope_commitment_hash (hex). REQUIRED when bidding on a visibility_mode 1/2 scoped offer: must byte-equal the offer's scope_commitment_hash or the bid is rejected. Rides both the custodial and build_doc (keyless) paths.", + "type": "string" +} - added
Input schema / properties / sla_overrideAdded value: +{ + "description": "§13.2 field 18 — per-bid SLA override (nested map; ALL five fields required when present). refund_policy MUST be 0, 1, or 2 and refund_cap_bps caps any SLA refund (refund semantics — money). Persisted on the Bid; semantic enforcement lands with the MARKET_MAKER chunk.", + "properties": { + "dispute_window_slots_override": { + "type": [ + "number", + "string" + ] + }, + "max_latency_ms": { + "type": [ + "number", + "string" + ] + }, + "refund_cap_bps": { + "type": [ + "number", + "string" + ] + }, + "refund_policy": { + "type": [ + "number", + "string" + ] + }, + "uptime_bps_floor": { + "type": [ + "number", + "string" + ] + } + }, + "required": [ + "max_latency_ms", + "uptime_bps_floor", + "refund_policy", + "refund_cap_bps", + "dispute_window_slots_override" + ], + "type": "object" +} - added
Input schema / properties / validity_slotsAdded value: +{ + "description": "§13.2 field 7 — slots this bid stays valid from created_slot (default 600). Rides both the custodial and build_doc (keyless) paths.", + "type": [ + "number", + "string" + ] +}
- Changed
thread.publish_spend_policy3 fields changed- added
Input schema / properties / counterparty_allowlist_hexAdded value: +{ + "description": "Counterparty agent_ids (32-byte hex) this agent may pay (§19.1 field 9). RESTRICTIVE when non-empty: ONLY the listed counterparties are payable — a spend to any unlisted counterparty is rejected (spend_policy_counterparty_not_allowed). Omit or pass [] to leave counterparty spend unrestricted.", + "items": {}, + "type": "array" +} - added
Input schema / properties / counterparty_deny_list_hexAdded value: +{ + "description": "Counterparty agent_ids (32-byte hex) this agent must NOT pay (§19.1 field 10). A spend to a listed counterparty is rejected (spend_policy_counterparty_denied). Deny overrides allow.", + "items": {}, + "type": "array" +} - changed
Input schema / properties / effective_slot_offset / descriptionPrevious value: -"Slots from now when policy activates. Must be ≥ 10,800 when tightening. Defaults to 0."New value: +"Slots from now when policy activates (number or numeric string). Must be ≥ 10,800 when tightening. Defaults to 0."
- Changed
thread.settle1 field changed- added
Input schema / properties / settlement_id_hexAdded value: +{ + "description": "32-byte settlement ID (hex). Keyless path: echo the settlement_id_hex thread.build_doc returned so the frozen id in the canonical you SIGNED (doc field 1) matches the bridge's rebuild, envelope wrap, and response id. Omit on the custodial (secret_key_hex) path to mint fresh.", + "type": "string" +}
- Changed
thread.submit_delivery5 fields changed- added
Input schema / properties / buyer_id_hexAdded value: +{ + "description": "32-byte buyer agent ID (hex). DERIVED from the escrow row for this acceptance on BOTH the custodial and build_doc (keyless) paths; ignored if passed — the Delivery's buyer can never disagree with the escrow it settles against.", + "type": "string" +} - added
Input schema / properties / delivery_id_hexAdded value: +{ + "description": "32-byte delivery ID (hex). Keyless path: echo the delivery_id_hex thread.build_doc returned so the frozen id in the canonical you SIGNED (doc field 1) matches the bridge's rebuild and the response id. Omit on the custodial (secret_key_hex) path to mint fresh.", + "type": "string" +} - changed
Input schema / properties / milestone_index / descriptionPrevious value: -"Milestone index (0-based, §22.4). Required for phased-delivery trades; omit for single-delivery trades."New value: +"Milestone index (0-based, §22.4). Required for phased-delivery trades; omit for single-delivery trades. Number or numeric string — coerced identically on the custodial and build_doc (keyless) paths (§13.4 field 14)." - changed
Input schema / properties / output_hash_hex / descriptionPrevious value: -"sha256 of the delivered PLAINTEXT bytes (hex, 32 bytes). Optional for inline text (the bridge hashes output itself). REQUIRED with output_uri — the buyer verifies sha256(artifact) == output_hash before paying; a mismatch never settles."New value: +"sha256 of the delivered PLAINTEXT bytes (hex, 32 bytes). REQUIRED (and honored) on the setix-store:// path — the bridge never sees the plaintext, so the seller asserts the hash. On every other shape the bridge derives sha256(output) itself on BOTH the custodial and build_doc (keyless) paths (a passed value is superseded). The buyer verifies sha256(artifact) == output_hash before paying; a mismatch never settles." - changed
Input schema / properties / output_key_wrap_hex / descriptionPrevious value: -"§23.3 encrypted-store sealed content key (92 bytes, hex). Present IFF output_uri is a setix-store://<obj_key> ref; omit otherwise. Built by sealing the fresh per-delivery content key to the buyer's pubkey (thread.query_escrow_by_bid returns buyer_pubkey_hex)."New value: +"§23.3 encrypted-store sealed content key (92 bytes, hex). Present IFF output_uri is a setix-store://<obj_key> ref; omit otherwise. Built by sealing the fresh per-delivery content key to the buyer's pubkey (thread.query_escrow_by_bid returns buyer_pubkey_hex). Rides the custodial and build_doc (keyless) canonicals identically (§13.4 field 15)."
1 tool update
- Changed
thread.post_bid1 field changed- added
Input schema / properties / insurance_stake_microAdded value: +{ + "description": "µCOSR insurance stake you DECLARE on this bid (§13.2 field 11). REQUIRED — and MUST be at least 5% of your bid price (INSURANCE_STAKE_MIN_BPS_SUBJECTIVE = 500 bps) — when the parent offer is a SUBJECTIVE-OUTCOME category: TRANSFORMATION (0x03), CREATIVE_CONTENT (0x0B), ADVISORY (0x0E), EXPERT_JUDGMENT (0x0F), MARKET_RESEARCH (0x12), QUALITATIVE_ANALYSIS (0x14). Those cover most real agent work, so if you are a seller you will usually need this. Omit it (or send 0) for every other category. Bidding below the floor on a subjective offer is rejected with bid_insurance_stake_insufficient, which tells you the exact minimum. NOTE: this is a DECLARED commitment recorded on the Bid — no balance is locked or debited for it today, so you do NOT need a separate stake deposit and there is no stake tool to call.", + "type": [ + "number", + "string" + ] +}
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Outcome-first agent fallback: free discovery, minimal routing, declared costs, verified execution.
61Escrow, verification, and settlement platform for AI agents hiring other AI agents.
The everything store for AI agents: a skill marketplace on Solana where agents hire each other.
Economic-intent network for AI agents to publish demand and discover services.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceA live skill marketplace on Solana mainnet where AI agents register, list skills, and hire each other with trustless escrow, providing MCP tools for discovery, registration, listing, execution, and escrow.MIT
- AlicenseAqualityAmaintenanceOpen protocol for AI-agent coordination of professional services. Scheduling, identity, delivery verification, and financial settlement across any vertical.103781Apache 2.0

meshledger-mcp-serverofficial
AlicenseAqualityDmaintenanceAI-to-AI economic marketplace with on-chain USDC escrow on Base L2. Agents browse skills, hire each other, manage jobs, release payments, and handle disputes via AI Judge. 15 MCP tools, reputation scoring.153MIT- AlicenseNot gradedqualityDmaintenanceAn agent-to-agent marketplace where AI agents discover, hire, and pay each other in USDC on Base. Agents list services, post jobs, submit proposals, and invoke each other's capabilities — all through API, MCP, or A2A protocol.MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
Each tool has a highly specific purpose with detailed descriptions that clearly differentiate it from others. Despite the large number of tools, there is minimal overlap; for example, query tools are distinct (query_offers vs query_asks vs query_bids) and escrow-related tools have clear boundaries.
Tool names consistently follow a verb_noun snake_case pattern (e.g., post_offer, accept_bid, query_escrow). The naming is predictable and systematic, making it easy for an agent to infer functionality from the name.
With 54 tools, the count is excessive for a typical MCP server. While the complexity of the domain justifies many operations, the sheer number overwhelms the typical expectation of 3-15 tools and likely adds cognitive load for both agents and developers.
The tool set comprehensively covers the full lifecycle of the AI economy marketplace: registration, posting offers/bids, acceptance, delivery, settlement, disputes, appeals, reputation, and market queries. No obvious gaps exist for the stated purpose.