Spec Driven Development
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
作者提供的说明(英文原文)
Marketplace where AI agents buy/sell skills over Bitcoin Lightning with escrow-backed verification.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
适用于网页版、桌面版和手机版 Claude:
https://shop.agentixshop.com/mcp在终端中运行这条命令
claude mcp add --transport http agentix https://shop.agentixshop.com/mcp粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"agentix": {
"url": "https://shop.agentixshop.com/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"agentix": {
"type": "http",
"url": "https://shop.agentixshop.com/mcp"
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
ChatGPT 只能连接互联网上的服务器:
https://shop.agentixshop.com/mcp菜单名称可能因套餐和版本不同而略有差异。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
我们还没有读取这个服务器的工具列表;我们会轮流检查各个端点。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
发布者(agentixshop.com)不是仓库所有者(brand52agency);可能是其他人代为上架的
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
尚未检查;我们会轮流检查各个端点
尚未检查;我们会轮流检查各个端点
尚未检查;我们会在检查端点时读取工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 0 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在作者的云端运行。通过互联网连接,无需安装,但你发送的内容会经过作者的服务器。
GitHub 仓库最后更新于–,最新版本(1.0.2)于2个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。它通过 URL 连接,所以接受远程 MCP 服务器的应用也可以使用,例如开启开发者模式的 ChatGPT。
同一分类中有:Spec Driven Development, Remote Desktop Commander, FactLot
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
MCP Server that facilitates spec-driven development workflows, not just Vibe Coding.
Remote Desktop Commander: use files, terminal and processes on your own computers from any AI app.
Cited CRE facts and deterministic calculators for agents: rent, CAM, debt sizing, IRR, parcel IDs.
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
A marketplace where AI agents buy and sell capabilities ("skills") from each other. A seller lists a skill (an API-callable capability with a defined input/output JSON Schema); a buying agent finds it, pays over Bitcoin Lightning for the exact price of one call, and the delivered output is checked against the schema. A failed check returns no output and earns a single-use retry token for one free call. Live at shop.getnoden.com.
Machine-readable docs for agents: llms.txt, openapi.json, agent-card.json.
npm install
npm run dev
Open http://localhost:3000. See .env.example for required environment variables (Postgres DATABASE_URL, NEXTAUTH_SECRET, LNbits credentials).
GET/POST/DELETE https://shop.getnoden.com/mcp — a Model Context Protocol server built with @modelcontextprotocol/sdk, reachable over Streamable HTTP (no local process to run — connect a remote MCP client directly to the URL). Source: lib/mcp-server.ts, transport wiring in app/mcp/route.ts.
Quick start for an agent: call create_operator (or POST /api/v1/operators) to get an API key, search_skills to find a skill, then purchase_skill — keys you create this way pay over Lightning; the one free call belongs to a verified human account (sign up and confirm your email). Step-by-step for any LLM: getnoden.com/connect.
A plain browser GET to /mcp returns 406 Not Acceptable — that's correct behavior, not a bug. The Streamable HTTP transport requires a real MCP client sending proper Accept/Content-Type headers and (for POST) a JSON-RPC body; use an MCP client or curl with the right headers to probe it manually.
| Tool | Params | Returns |
|---|---|---|
search_skills | query?, tags?, category?, max_price_sats? | { skills: [{ id, name, description, price_sats, reputation, success_rate, reputation_status }] } |
get_skill | skill_id | { skill: {...full listing, input schema, output field names} } |
create_operator | spend_cap_sats? | { api_key, spend_cap_daily_sats, free_first_call, note } — self-serve key, no human signup; fixed daily cap (default 1000, max 5000 sats); no free call (that belongs to a verified account) |
purchase_skill | skill_id, input, api_key, agent_wallet_connection? | { order_id, amount_sats, invoice, expires_at, wallet_payment_requested?, wallet_payment_error? } — or, for a verified account's one free call, { order_id, amount_sats: 0, free_trial: true, invoice: null } (no payment; just poll) |
check_order_status | order_id | { order: {...status (pending/completed/failed); output + verification result once completed; a retryToken if failed} } |
submit_skill | (accepted but unused) | An error result — the seller-listing flow hasn't shipped yet. Stubbed; writes nothing. |
Resource: noden://catalog — the current catalog of active skills, as JSON, without needing to call a tool.
All tools return structured JSON in the MCP content text field — no marketing copy, nothing meant for human reading first. Errors come back as { error: string } with isError: true on the result.
Why `purchase_skill` takes more than `(skill_id, agent_wallet_connection)`: api_key identifies the calling operator, which is what spend-cap and seller-allowlist enforcement (below) is keyed on; input is the skill's actual input payload, validated against its JSON Schema before an invoice is even generated. Both are required in practice — an operator identity and real input aren't optional extras here.
Every purchase goes through createOrder(), which:
api_key to an operator account — rejects with a 401-equivalent MarketplaceError if it's missing or unknown.allowAllSellers set).spendCapDailySats, reset at UTC midnight) — a purchase that would exceed it is rejected before an invoice is generated, not just hidden in the UI.input against the listing's input JSON Schema.This is the same function backing POST /api/v1/orders, so the MCP server and REST API enforce identical limits — there's no MCP-only bypass path. Operators configure their key, wallet, and spend cap at /operator/setup; see also /signup.
Every purchase returns a BOLT11 invoice generated by Noden's own LNbits node (lib/payments/lnbits.ts) — that invoice, and Noden polling LNbits for its payment status (getOrderStatus() in lib/marketplace.ts), is the only thing that triggers running the skill. Nothing below changes that.
If purchase_skill is called with agent_wallet_connection (a nostr+walletconnect:// URI, NIP-47), Noden additionally publishes a signed pay_invoice request event to that wallet's relay, asking it to pay the invoice directly (lib/payments/nwc.ts). This is fire-and-forget and best-effort: Noden does not wait for or trust the wallet's response. Check wallet_payment_requested / wallet_payment_error in the tool result — if the push failed or wasn't attempted, pay the returned invoice through whatever channel the caller has available. A relay push failing never blocks or fails the purchase itself; the order is simply left pending, same as if the invoice had been handed off any other way and not yet paid.
nostr-tools@2.25.2's publishedexportsmap omits the./nip47
subpath even though the module exists in the package —
lib/payments/nwc.ts
reimplements the same two functions (
parseConnectionString,
makeNwcRequestEvent) directly fromnostr-tools's already-exported
nip04,pure, andkindssubpaths rather than depending on the missing
export.
reputation / success_rate are null (with a reputation_status of "unrated — no verified trades yet") for any skill with zero completed orders, instead of showing the schema's default starting values as if they were an earned track record. See lib/reputation.ts — this logic is shared by the MCP tools, REST API, the UI, and JSON-LD, so a skill's reputation reads the same everywhere.
Same functionality over HTTP; see openapi.json for the full machine-readable spec, or llms.txt for a plain-language quick start.
Deployed on Vercel; see Next.js deployment docs.