Skip to main content
Glama
deenesjakoruzh
nod-protocol

nod-mcp-server

Official
by nod-protocol
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

nod-mcp-server

这就是 AI 智能体与企业交互的方式——不是通过抓取，而是通过读取结构化的清单。这个参考 MCP 服务器教会任何兼容 MCP 的客户端（Claude Desktop、智能体框架、IDE）读取企业位于 https://{domain}/.well-known/nod.json 的 nod.json 清单，并回答关于企业能做什么的实际问题：订餐、预约、搜索产品、查询价格等。

它公开了两个工具——lookup_nod 和 check_capability——并捆绑了四个在本地运行的演示清单，因此该演示无需任何外部依赖即可开箱即用。

安装

git clone <this repo> nod-mcp-server
cd nod-mcp-server
npm install
npm run build

需要 Node.js 20+。

Related MCP server: Vexi MCP Server

运行演示清单服务器

目前几乎没有真实网站发布 nod.json，因此该仓库捆绑了四个示例清单（餐厅、电子商务、SaaS、医疗保健）并在本地提供服务。

npm run demo:manifests

你应该看到：

NOD demo manifest server listening on http://localhost:3456
  http://localhost:3456/demo-restaurant.localhost/nod.json
  http://localhost:3456/demo-shop.localhost/nod.json
  http://localhost:3456/demo-saas.localhost/nod.json
  http://localhost:3456/demo-health.localhost/nod.json

在演示期间保持此终端运行。MCP 服务器会自动将任何 *.localhost 域名路由到此服务器。

配置 Claude Desktop

在 macOS 上打开（或创建） ~/Library/Application Support/Claude/claude_desktop_config.json（在 Windows 上为 %APPDATA%\Claude\claude_desktop_config.json）并添加：

{
  "mcpServers": {
    "nod": {
      "command": "node",
      "args": ["/ABSOLUTE/PATH/TO/nod-mcp-server/dist/index.js"]
    }
  }
}

将 /ABSOLUTE/PATH/TO/nod-mcp-server 替换为此检出目录的完整路径（例如 /Users/you/projects/nod-mcp-server）。重启 Claude Desktop。现在你应该能在 Claude 的工具选择器中看到 nod 服务器，其中包含两个工具：lookup_nod 和 check_capability。

60 秒演示脚本

在终端运行演示清单服务器并配置好 Claude Desktop 后，将这些提示词依次粘贴到 Claude 中。

1. "Look up the NOD manifest for demo-restaurant.localhost"

Claude 调用 lookup_nod({ domain: "demo-restaurant.localhost" }) 并返回类似以下内容：

# Pike Place Noodle House  (restaurant)
Hand-pulled noodles, dumplings, and regional Chinese classics...

- URL: https://demo-restaurant.localhost
- Manifest: http://localhost:3456/demo-restaurant.localhost/nod.json

## Declared capabilities
  - purchase
  - booking
  - view_menu
  - order_food
  - book_table

## Supported actions
  - purchase → https://demo-restaurant.localhost/api/orders [auth: api_key]
  - booking  → https://demo-restaurant.localhost/api/reservations [auth: api_key]
  - search   → https://demo-restaurant.localhost/api/menu/search [auth: none]

2. "Can I order food from demo-restaurant.localhost?"

Claude 调用 check_capability({ domain: "demo-restaurant.localhost", action: "order_food" })：

YES — demo-restaurant.localhost supports "order_food".
Manifest declares "order_food" under discovery.mcp_server.capabilities.

Endpoint: POST https://demo-restaurant.localhost/api/orders
Authentication: api_key
Matched via: discovery.mcp_server.capabilities

Constraints:
{ "require_human_confirmation": { "purchases_above": 150, ... },
  "rate_limits": { "transactions": { "requests": 10, "period": "minute" } },
  "allow_automated_purchases": true }

3. "What actions does demo-shop.localhost support?"

Claude 调用 lookup_nod({ domain: "demo-shop.localhost" }) 并总结：产品搜索、定价、库存检查以及受 OAuth2 保护的订单下单——具有 500 美元的人工确认阈值和 60 天退货政策。

奖励提示词

  • "Book an appointment at demo-health.localhost — what does that flow require?" → 返回预约端点、必填字段（patient_name, DOB, reason, provider_id, preferred_date）、OAuth2 作用域以及取消政策。

  • "Does demo-saas.localhost allow automated purchases?" → 返回 NO 以及人工回退 URL，因为清单设置了 allow_automated_purchases: false。

工具参考

lookup_nod

输入

类型

描述

domain

string

仅域名（无协议，无路径）。*.localhost 域名会被路由到捆绑的演示服务器。

获取 https://{domain}/.well-known/nod.json，如果失败则回退到 https://{domain}/nod.json。返回结构化摘要：企业身份、声明的能力、支持的操作（包含端点 + 认证）、API 端点和联系方式。失败时返回明确的“未找到清单”消息。

check_capability

输入

类型

描述

domain

string

仅域名。

action

string

常用值：order_food, place_order, view_menu, book_table, book_appointment, search_products, find_provider, get_pricing, check_inventory, check_status, create_account, get_docs, contact_support。

获取清单并根据 transactions.capabilities, discovery.mcp_server.capabilities, support.contact.mcp_server.capabilities 以及结构化端点（transactions.purchase, discovery.search, information.pricing 等）检查该操作。返回是/否的结论、端点 URL、认证方法以及策略约束（速率限制、人工确认阈值）。

*.localhost 路由的工作原理

当 MCP 服务器收到以 .localhost 结尾的域名时，它会从 http://localhost:3456/{domain}/nod.json 获取，而不是正常的 well-known URL。这使得演示是自包含的——你可以将 Claude 指向 demo-restaurant.localhost 并获得真实结果，而无需任何 DNS 或 HTTPS 设置。

环境变量：

  • NOD_LOCAL_PORT — 演示清单服务器监听的端口（默认为 3456）

  • NOD_LOCAL_MANIFEST_SERVER — MCP 服务器用于 .localhost 查找的基础 URL（默认为 http://localhost:3456）

  • NOD_FORCE_LOCAL=1 — 将所有域名通过本地清单服务器路由（对于测试新示例清单的贡献者很有用）

下一步

使用 opennod.ai/protocol 上的 NOD 协议规范为您的企业发布 nod.json。编写一个最小的有效清单大约需要 30 分钟——一旦它在 https://yourdomain.com/.well-known/nod.json 上线，任何使用此 MCP 服务器（或任何其他支持 NOD 的客户端）的智能体都将能够发现您的企业并根据其能力采取行动。

许可证

MIT

Available Tools

2 tools
check_capabilityCheck a NOD capabilityA

Given a domain and an action (e.g. order_food, book_appointment, search_products, get_pricing, view_menu, book_table, check_status, create_account), fetches the business's NOD manifest and reports whether the action is supported, the endpoint URL, authentication requirements, and any policy constraints.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to check (e.g. "demo-restaurant.localhost").
actionYesThe action to check. Common values: order_food, place_order, view_menu, book_table, book_appointment, search_products, find_provider, get_pricing, check_inventory, check_status, create_account, get_docs, contact_support.

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full behavioral disclosure. It explains what the tool does and returns, but does not mention side effects, prerequisites (e.g., domain validity), or that it is read-only.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence covering purpose, input, and output. Very concise with no wasted words, though slightly dense; could be broken into two sentences for readability, but still effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description adequately covers return fields (supported status, endpoint, auth, policies). Input is fully described. Missing error handling and sibling differentiation, but sufficient for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by listing common actions, providing concrete examples that aid selection beyond the schema's generic string type.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool checks if an action is supported for a given domain, listing output details. It differentiates from the sibling 'lookup_nod' by focusing on a specific action check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus 'lookup_nod' or when not to use it. The description only implies usage through examples, lacking explicit context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

lookup_nodLook up NOD manifestA

Fetches a business's NOD Protocol manifest from https://{domain}/.well-known/nod.json (or the local demo server for *.localhost domains) and returns a structured summary: business identity, declared capabilities, supported actions, API endpoints, and contact methods.

ParametersJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to look up (e.g. "example.com" or "demo-restaurant.localhost"). Do not include scheme or path.

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry full behavioral transparency. It discloses the fetch action and return summary but does not address potential failure modes (e.g., domain not found, malformed manifest), rate limits, or authentication requirements. The description is adequate but incomplete for a safe agent invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that efficiently conveys the main purpose and key details (URL pattern, return contents). It is front-loaded and includes relevant information without excess words. However, it is somewhat dense and could be split into two sentences for improved readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the low complexity (single parameter, no output schema), the description provides sufficient context: it specifies the source URL, the domain format, and the contents of the returned summary. It does not cover error handling or exact output structure, but for a simple lookup tool it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the single 'domain' parameter. The description adds context about the URL pattern but reiterates the format constraint already present in the schema. Since schema coverage is high, the baseline of 3 is appropriate; the description does not significantly add meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it fetches a NOD Protocol manifest from a well-known URL and returns a structured summary including business identity, capabilities, actions, endpoints, and contact methods. It uses a specific verb-resource combination and distinguishes itself from the sibling tool 'check_capability' by focusing on the full manifest.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains what the tool does but provides no guidance on when to use it versus the sibling 'check_capability', nor does it mention prerequisites or exclusions. The usage context is implied (looking up a domain's manifest) but lacks explicit alternative differentiation.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedcheck_capability
    • First observedlookup_nod
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have clearly distinct purposes: check_capability validates a specific action against a business's manifest, while lookup_nod retrieves and summarizes the entire manifest. There is no overlap or ambiguity between them, as one is for targeted validation and the other for general information retrieval.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern with snake_case naming: check_capability and lookup_nod. The verbs 'check' and 'lookup' are semantically appropriate and distinct, and the naming style is uniform throughout the set.

Tool Count2/5

With only two tools, the server feels under-scoped for its apparent purpose of interacting with NOD Protocol manifests. While the tools cover basic retrieval and validation, the lack of tools for actions like updating manifests, managing policies, or executing supported actions suggests a thin surface that may limit agent functionality.

Completeness2/5

The tool set is significantly incomplete for the NOD Protocol domain. It provides read-only access to manifests but lacks tools for creating, updating, or deleting manifests, or for actually executing the supported actions (e.g., order_food, book_appointment). This creates dead ends where agents can inspect but not interact with the business capabilities.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • nod-mcp-server

    opennod
    A
    license
    A
    quality
    D
    maintenance
    Enables AI agents to discover and interact with business capabilities by reading structured nod.json manifests from domains, supporting actions like ordering, booking, and searching.
    2
    MIT
  • Vexi MCP Server by getvexi

    Vexi MCP Serverofficial

    getvexi
    A
    license
    A
    quality
    D
    maintenance
    Enables MCP clients to search and retrieve structured business data from the Vexi API, allowing AI agents to get clean, typed business objects with identity, offerings, and trust signals.
    4
    8 npm
    MIT

  • agentweb-mcp

    zerabic
    A
    license
    A
    quality
    D
    maintenance
    Enables agents to search, retrieve, and contribute business data from a directory of 11M+ businesses across 195 countries, returning markdown prose by default.
    22
    115 npm
    3
    MIT

  • AgentRank MCP

    saviodamato
    A
    license
    A
    quality
    C
    maintenance
    Provides AI agents with access to real, verifiable businesses with provenance and source URLs, enabling natural-language business search and profile retrieval.
    2
    MIT