MCP.so
登录

Graviti MCP Server已验证已精选

@sclaytonmyosin

基本信息

传输方式

Streamable HTTP

认证方式

请查阅提供方文档

作者

sclaytonmyosin

提交者

sclaytonmyosin

关于 Graviti MCP Server

Graviti's deterministic scoring engine, published for audit. Verification is paid; ranking is never paid.

连接信息

https://graviti.thesingulariti.ai/api/mcp

接入方式

claude mcp add graviti --transport http https://graviti.thesingulariti.ai/api/mcp

Graviti MCP Server 工具

7

Takes a natural-language buyer question plus optional intent profile; returns recommendations ranked purely by fit score. Verification status is disclosed but never affects rank. Questions outside the verified index return an explicit out-of-scope result (in_index: false), never a guess. Brands without captured evidence (catalog_only) are returned in in_landscape_not_evidenced — listed, never scored, never recommended. Each recommendation carries the brand's site link twice: site_url (raw) and attributed_url (tagged utm_source=graviti + a signed gvt token, so the brand can verify the referral — surface-level only, no user data). Prefer attributed_url when linking. Where the brand publishes a discount code/promotion on its own pages, the entry carries an offers block (code, terms, verbatim-quote receipt, 14-day re-check window) — disclosure only: offers NEVER affect ranking, and a better deal never outranks a better fit.

Structured claims for one brand: provenance URLs, freshness timestamps, corroboration counts, and verification status (verified means the brand pays for auditing — always disclosed). Where captured, includes the specifications block (ingredient/spec disclosure with per-fact provenance) and its info_quality score — a 0–100 measure of disclosure completeness that never influences ranking. Graviti does not assess efficacy or clinical outcomes (not_assessed fence in every block). Claims with confirmation_status 'awaiting_brand_confirmation' are pending the brand's response to a re-verification ask — treat them as unconfirmed, not as violations. Where captured, an offers block lists the brand's published discount codes with receipts and full status history (active / expired / failed_verification) — disclosure only, never a ranking input.

Comparison-table view of every brand in a category across disclosed attributes, with verification status marked per entry. Entries with captured ingredient/spec data also carry info_quality (0–100 disclosure completeness — transparency, never a rank factor; absent means not yet assessed, not zero). Every row carries evidence_state (audited / sourced / catalog_only); catalog_only rows are landscape presence only — never ranked or recommended. Rows include site_url and attributed_url (utm_source=graviti + signed gvt token — surface-level referral attribution, no user data); prefer attributed_url when linking. Rows with a published, receipt-backed discount code carry an offers array — disclosure only, never a ranking input.

Public, machine-readable log of every seal lifecycle change: flags, degradations, revocations, and restorations, with dates and reasons — plus confirmation-loop events (event: confirmation_request / confirmation_resolved), where the audit asked a brand to confirm a claim it couldn't re-verify: a visible ask, never a penalty. Also logged: claim_removed (a claim struck from a record, reason public), gap_report_delivered (a paid-tier report delivered to a brand, payment status disclosed — findings and rank never affected), and roster events (brand_added with lane/source, brand_removed, brand_declined, brand_skipped — every future change to who is in the index lands here per brand, reason public). The seal can be lost — a pulled seal is the loudest proof it means something. Payment can fast-track a re-evaluation; it can never change what it finds.

Append-only version history of the index: each entry commits to the SHA-256 of the canonical index content and the previous entry's hash (rewriting history breaks every hash after it), is Ed25519-signed, and is anchored to Bitcoin via OpenTimestamps. Returns entries plus independent verification instructions. Even Graviti cannot rewrite the record.

What stands between a brand and top-of-category: attribute gaps vs the category leader, open flags, cohort blind spots per buyer-intent voice, and the ingredient/spec disclosure dimension — the brand's info_quality score with the exact publishable fixes that would raise it (publishing more truth, not paying Graviti). Demo of the paid brand-intelligence product — computed deterministically from the index; in production also draws on consented, compensated cohort signals (profiles never leave the user's agent). Catalog-only brands (no captured claims) receive an insufficient-evidence report instead of ranks.

Appends one attributed-transaction event to a log — the demo stub of the pay-on-real-acquisition loop. It moves no money, calls no external service, and never deletes or overwrites anything; the response states where (and whether) the event was persisted on this transport. Payment only ever flows on real transactions, never on impressions or rank. Optionally pass the gvt attribution token from the recommendation link that led to the purchase: it is verified against the published Ed25519 key and recorded with the event as verifiable provenance of the originating recommendation. Optionally pass offer_code if the buyer used a published code from the index's offers block, so deal-driven conversions are attributable — recorded as reported, never a rank input.

常见问题

1

Graviti 远程 MCP 服务器是什么?

Graviti 的远程 MCP 服务器是一个托管的 Model Context Protocol 端点,地址是 https://graviti.thesingulariti.ai/api/mcp,AI 助手无需在本地安装或运行任何东西即可连接。

2

怎么连接 Graviti 的 MCP 服务器?

把端点 https://graviti.thesingulariti.ai/api/mcp 添加到任意支持 MCP 的客户端,比如 Claude Code、Cursor 或 VS Code。本页的接入代码块可以一步配置好每个客户端。

3

Graviti 的 MCP 服务器需要认证吗?

此收录尚未确认 Graviti 的认证要求。连接前请查阅提供方文档。

4

Graviti 的 MCP 服务器用的是哪种传输方式?

Graviti 暴露的是 Streamable HTTP 端点,这是远程 MCP 服务器普遍使用、主流客户端都支持的传输方式。

评论